More on mobile

Mobile is so hot that we would like to say more on this topic. In fact, there really are some important things which are worth to talk.

1) Small size of screen and touch
When the focus is shifted from desktop to mobile device, the most significant difference comes from the screen size. For desktop monitor, you can arrange your viewer's layout in a rather generous way. The control panel hosting working buttons can be put together like this:

screenshot.png

However, in mobile device, the screen size becomes small. For now, the devices of 10 inch size of screen with about 1000*800 resolution dominate the tablet market and we believe that screen size will not become much bigger in the future. After all, the portability is the most well known selling point for tablet. For smartphone, the size of 3.5 inches with 400*800 resolution is becoming common. Due to the small screen size of mobile devices, the most of the space should be left to image viewing rather than the dicom information navigation such as Patient-Study-Series-Image hierarchical tree view. The smaller screen than that used in traditional desktop workstations also is a potential factor to affect the underlying architecture of dicom viewer. For example, now it seems not a good idea to deploy advanced hanging protocol which can render several images simultaneously on the screen except for thumbnail mode. Stack mode might be more suitable than tile mode. “Pan” is believed to be used in mobile device more often than before due to the limited screen size.

To save the space, it is not wise to deploy several buttons that would not be a concern in desktop. On the other said, if it is absolutely necessary to place buttons in the layout, the button size should be bigger than its counterpart in desktop computer because your primary pointer device is finger but not mouse. The click granularity has big difference now. Based on this fact, the traditional user behaviors may have to change. For example, to measure the value of a specific pixel, clicking with finger won't make sense. By the help of a fake pointer to move around perhaps is a good idea.

Touch events bring very interesting user experiences. In particular the multiple touches can give some sort of new manipulation approaches which are impossible with mouse. Right now, use can pitch the screen to achieve the zoom in/out. It seems more intuitive than before. Actually, for the most often used operations , pan, zoom and window/level, can be totally controlled by touch events even without necessity to place buttons. The sole purpose of those buttons is to be as a switcher to select the working tool. This is also true to replace the right button menu.

In short, the UI design has to be re-considered seriously in order to follow mobile devices' new characteristics.

2) Can have different orientations
This is very different from the desktop application. Even it is possible to forbid such a cool feature in mobile devices, but it sometime is required by users. For developers, this means it is better to prepare two suites of UI in case the orientation is changed. A commonly used practice is to separate the UI view layer clearly from the presentation layer in order the view layer can be freely interchangeable.

3) Have lower processors
For most of mobile devices, the 1GHz or so CPU is used. The processing power is close to the CPU power of desktop in 1999. When we recall the desktop dicom viewer at that time, CPU at current frequency seems not a big bottleneck because there were several commercial dicom viewer products that worked pretty well in the early of this century.
Furthermore, the more powerful CPUs are being equipped for the mobile devices. The CPU with 1.5G Hz Tegra 3 four cores has been used in some products. It is optimistic to think the CUP should not a big bottle neck for the dicom viewer. Even so, the lower processor does degrade the performance somehow. It is a good idea to avoid unnecessary computations, for instance, complex XML’s parsing, multiple loops of mathematical calculations or complicated coding/decoding.

4) Have limited physical memory
Now 512-1024 M RAM seems the main stream configuration. This is sufficient for most applications such as chat tools, multimedia website browsing. But for dicom viewer, due to the fact that medical images are normally of big size, the 512M is not good enough at all. A commonly used practice in desktop viewer to preload many images into the memory won’t work well any more. On demand image loading might be a wiser strategy. This decision will impact the overall architecture and must be considered very carefully beforehand.

5) Can be disconnected
Mobile means lightweight, portable and small. On the other hand, the limited storage makes it rely on the internet to acquire more information and working set. The networking might be disconnected. Never caching any data in local storage sometimes is a desired feature for dicom viewer for the sake of privacy and security, that being said, once the connection is lost, nothing will remain in the client mobile devices. However, if not the case, for example, to improve the workflow and keep the radiologist able to continue to work even in a temporary networking break down, the offline capability of dicom viewer should be considered.

6) Limited battery power
As a mobile device, it usually rely on the battery to support the running. In healthcare IT, the best practice is to charge once and work one day. You can't image the doctors have to connect to the power outlets to charge from time to time. So it is important to design the algorithms carefully to avoid intensive computing.

7) Performance again
For html5 based dicom viewer, the critical issue is still the performance. Our implementation heavily relies on the browser. We won't dive into the detail much here by our own. Instead, we'd like to recommend two good references for your interests:
a)Android or iOS: Which platform is better for HTML5?
b) Testing HTML5 Performance Across Mobile Browsers

You are also encouraged to take your testing with our product. Though not play with Android's mobile chrome, we think that browser should be better than any others.