DigitalNeurosurgeon.com

Last week Apple introduced the iPad, a tablet device in the middle between iPod/iPhone and MacBook computers. Immediately there were many responses on the web, both positive and negative. Let’s start with the funniest one that touches the topic we’ll discuss in detail.

A comment that kept coming back in many reactions, is the lack of Flash support. Whether the topic is 8 Things That Suck About The iPad or iwantflash.com, the message is the same as the blogs from Adobe people like Serge Jespers and The Flash Blog: Flash should be added to the iPad!

But should it? Apple’s official comment after iPhone release has been that Flash was too resource consuming, and for a phone that comment has been accepted. In the meantime anyone who has been following the App Store development and Steve Job’s keynotes knows that the App Store is a lucrative initiative, and allowing websites to display Flash-based games (especially games) will reduce Apple income. All right, that’s business, isn’t it?

The Apple iPad has been described as “impossibly fast” with Apple’s own A4 processor. BBC has high expectations of the new device, as has The Guardian. And from a medical perspective, opinions are mixed. John Halamka, CIO of Harvard Medical School, is in doubt about the success in healthcare, doc2doc is more negative. The same can be said for Healthcare IT Squad.

What is my opinion, as an IT-minded medical doctor? I am looking forward to the iPad, but in the first place because I want an affordable color-enabled e-reader for scientific literature. Second, this e-reader (or iReader, as you want) is programmable to perform tasks. Which could support guideline implementation. Whether you call this e-guidelines or clinical decision supporting systems, is up to you. As long as we both know what we’re talking about.

Is Flash necessary for that? No, but it would help. I fully agree with the excellent post of John Nack, and as a Flex-developer I definitely would like to program in Flex and ActionScript. I am really not fond of Objective C, it’s unneccesarily complicated. Who needs a separate @interface and @implementation?

Adobe’s initiative of the Open Screen Project is good. Even better, I think it is very good, and I am glad that companies like Google, HTC, Nokia and RIM are supporting it. On the other hand, depending on the sort of application, Flash may be just “too much”. I work on a new MacBook Pro model, but remaining battery really goes down if I have some Flash sites open. As much as CPU usage and core temperature goes up. So it perfectly understandable that the new mobile Firefox will disable the Flash plugin as the default setting. Reason: too much energy consuming. Although Mozilla offers a good alternative: you can choose to enable it, but then on your own responsibility.

So I do have some suggestions for developers, Apple and Adobe.

To developers: I have high expectations from Adobe’s Flash Player 10.1 in combination with the Open Screen Project. I think Adobe’s technologies are very promising, targeting almost all devices, except the iPhone and the iPad. For those latter two, you have alternatives besides XCode. Flash CS5 will provide export as native iPhone apps, OpenPlug’s Elips Studio 3 seems a fantastic tool for Flex developers who want to do iPhone development, and there is always the alternative to keep apps purely web-based. This skips the App Store, which you may like for reasons described on O’Reilly Radar here and here, as well as on Adobe’s Flash platform blog.

To Apple: you make wonderful hardware and software, and in the first place I think it is your right to determine how you want to incorporate your software on your hardware. But for the future, I think you do need to offer people choices. You have been criticized for coupling the iPhone to just one telecom provider, and you had to let go of your strict criteria. Don’t make countries create laws for open and accessible platforms. Offer people choices. If you want them to pay for that, that’s your right. But let them choose. Look at what Firefox did, and learn a lesson. Allow people to install Flash on their own risk, of wich decreased system performance might be the major one for badly designed websites. These are included in the web experience you promise us on the iPad, but that’s not delivered now.

To Adobe: stop whining. If Apple decides not to offer Flash, that’s too bad for all of us, but let’s find an alternative then. Your CS5 iPhone efforts and OpenPlug’s efforts show one opportunity. Google Web Toolkit (GWT) shows you the other. For the App Store, converting ActionScript code for rich media content to Objective C is the best you can do now. Focus on that, because Apple will allow native iPhone apps in the App Store. Of course. For web content, find a way to do the same with ActionScript that GWT does with Java: convert it to HTML, CSS and JavaScript. That won’t work for everything, but I think that many decent Flex apps could work this way. Then you can win the battle: rich media content goes the the App Store with a separate notice on the website, if viewed on the iPhone. Flex-driven apps can be translated “a la GWT” and are visible as well. Maybe with some inconsistencies due to different browsers and JavaScript versions, but that’s still beter than no Flash (or no up to date Flash) at all.

So to answer my own question: bashing or flashing the iPad? Neither of both! Looks like a nice iReader+ to me, with basic web capabilities and some iPhone features. One that’s fast, has no booting time, and with a large screen. And one that runs Papers! That’s not bad, is it?

The SLIC application on subaxial cervical spine injury has an updated interface now. Here is a screenshot (click for full size version):

User testing revelead a minor issue that caused some confusion. The abbreviation “DSS”, used for Decision Supporting System, also stands for Dutch Spine Society. And it made me realize that “DSS” is not really self-explanatory… so the buttons at the bottom of the screen have been updated.

Another request was to make the description of the decision tree (which displays it full title under the selection component) clickable. This also has been changed (from UITextView to UIButton with customized skin): now the user can go into Questions-mode immediately by clicking the text.

As Steve Krug writes in his book, the issue of usability comes down to that one point: “Don’t make me think!“

A new version of the NeuroMind iPhone app has been released (now version 0.8). Some new scores have been added, like the CHADS2. Most important, the core content of the WHO Safe Surgery checklist has been added. The items are available in three separate screens (Before Anaesthesia, Before Skin Incision, and Before Leaving The Operating Room) for easy reading. After rotation to landscape mode, the device automatically shows the full checklist.

Here are some screenshots (click for large version):

The official release (of version 1.0) is expected in first or second quarter of 2010.

The journal Oncology Times published an article about “Oncologists Using Twitter to Advance Cancer Knowledge” on their website. And they notified me, using Twitter of course, that my profile is mentioned in the PDF version of the article (free download from their website).

@OncologyTimes on @DigNeurosurgeon

Also, the editors of Neurosurgery have started using Twitter, and I am glad to be in their “following” category. They already retweeted a message on the NeuroMind app. Curious to know if they like SLIC as well…

Anyhow, it’s nice to see that Twitter also gets adopted for “serious use” instead of just notifying that somebody has just eaten breakfast. We’ll see how it evolves in the future!

It took me some time before I had it working: automatically resizing an image in the iPhone’s UIWebView component.

I want to load the image in a UIWebView instead of a UIImageView, as I get all the multitouch functionality (especially zooming) automatically included. Suppose this is my interface (.h) file:

1
2
3
4
5
6

@interface TestImageStretchViewController : UIViewController {
	IBOutlet UIView	*imageView;
	IBOutlet UIWebView *imageWebView;
}
// ... rest of interface content including function (IBAction) declarations
@end

Now, in my first version, I loaded the image directly in the UIWebView with the loadRequest instance method:

1
2
3
4
5
6
7
8
9
10
11
12
13

/*
 ** Display image in UIWebView using loadRequest
*/
- (void) showImageWithLoadRequest {
	// Create URL request for image file location
	NSString *imageName = [[NSBundle mainBundle] pathForResource:@"test_image" ofType:@"png"];
	NSURL *imageURL = [NSURL fileURLWithPath: imageName];
	NSURLRequest *imageRequest = [NSURLRequest requestWithURL: imageURL];
 
	// Load image in UIWebView
	imageWebView.scalesPageToFit = YES;
	[imageWebView loadRequest: imageRequest];
}

This works fine, but with one disadvantage: the image is displayed smaller than its actual size. If the user double taps on the screen, the device fits the image to the size of the UIWebView. Why can’t I do this automatically? I tried setting the UIView’s autoresizingMask property to UIViewAutoresizingFlexibleWidth, but this did not solve it. I also tried setting the UIWebView’s scalesPageToFit to YES, but again: no difference. The only difference I found, is when scalesPageToFit is disabled, double tapping does not make a difference: the image remains small.

The solution came after reading this forum item on iPhoneDevSDK.com. The idea is that UIWebView cannot determine the size of the image, this has to be provided in HTML code. So the suggestion was to use loadHTMLString instead of loadRequest, and to set a value for the width of the image in HTML.

1
2

NSString *html = @"<html><body><img src='http://www.domain.com/path/to/your/image.jpg' width='100%' height='100%'></body></html>";
[webView loadHTMLString:html baseURL:nil];

In my case, this was not successful, but it did offer the key to the solution. I found that setting the width to 100% did only work when scalesPageToFit was disabled. This was not what I wanted to do, because this disabled zooming as well. So -arbitrarily- I set the width to 900 and I got great results for all images (charts) that I use in the SLIC app. Funny value, because I expected that 320 should be fine (the iPhone’s width resolution), but this was too small apparently.

So here is how I do it now:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/*
** Display image in UIWebView using loadHTMLString
*/
- (void) showImageWithLoadHTMLString {
	// Create URL string for image file location
	NSString *imageName	 = [[NSBundle mainBundle] pathForResource:@"test_image" ofType:@"png"];
	NSURL	 *imageURL	 = [NSURL fileURLWithPath: imageName];
 
	// Create HTML string from image URL
	// Width-value is arbitrary (and found experimentally): 900 works fine for me
	NSString *htmlString = @"<html><body><img src='%@' width='900'></body></html>";
	NSString *imageHTML  = [[NSString alloc] initWithFormat:htmlString, imageURL];
 
	// Load image in UIWebView
	imageWebView.scalesPageToFit = YES;
	[imageWebView loadHTMLString:imageHTML baseURL:nil];
}

Mission accomplished! :-)

The New Year’s break has been quite productive for me. After the progress with the NeuroMind application, I could make serious progress on the SLIC application as well.

As a reminder, SLIC is a subaxial cervical spine injury classification system, described by Vaccaro et al (Spine, 2007). Based on this classification, some evidence-based algorithms on the surgical approach to subaxial cervical spine injury have been described by Dvorak et al (Spine, 2007). I liked both articles, and have developed an iPhone application that facilitates application of the system.

In my opinion, the application can be considered as finished now. Waiting for some last beta testing results, I do not expect to make serious modifications anymore. After some struggle with the code, the application now displays the decision chart automatically full screen if it is selected. Using multitouch gestures on the iPhone (“pinching”) it can be zoomed in for better reading. It works great on XCode’s iPhone simulator, although there seems to be a small delay in loading the chart on my device.

Further progress includes an improved version of the SLIC classification system, which is shown by rotating the device to landscape mode (“horizontal”). It also includes references to the articles mentioned above. The last addition which I think I need to provide, is a disclaimer.

Here is an updated screenshot compilation of the app (click for large version):

SLIC version 0.9

I hope to see you soon…. in the App Store!