Main
Posts
Links
Guest Book
|
Home
JohnWargo.com
|
Friday, 26 March 2010 17:20 |
|
A reader was kind enough to comment on my article: What Were They Thinking #6 and point out that the issue I was writing about was caused by my personal settings on the BlackBerry. If you look at the figure, you'll see that I'm clearly going blind (just kidding, just having trouble reading things) and have the font on my BlackBerry device cranked up high. The reader was right, the problem I was complaining about was my fault, but I contend that it still never should have happened. Here's my take on this:
First of all, since I'm looking at a listing of free apps, there's no need to list 'Free' for every item in the list. They're all free, there's no need to take up the screen space (and processing time to render) content that is not needed. Do you agree that highlighing the 'freeness' of a free application that's clearly already fee is a waste?
Second, although I agree that the issue I'm reporting is related to my personal font settings, it is the responsibility of the developer to detect the size of the fonts being used and adjust rendering on the screen accordingly. The developer of the application should have detected the font size (they alread did since we can see they used my font settings to render the screen) and make sure everything fits correctly using that font. There's no reason he or she couldn't have seen that the text as written was not going to fit into the allocated space (using the settings I've defined) and wrap the text on the screen so me, the user, would be able to read the entire application name. This is something I had to do in my Official's Record Keeper application in all of the reports. For any text I wanted to write to the report canvas, I had to check it's width and wrap it manually in the code. It's a pain in the you know what, but it's something that should have been addressed by the developer and I stand by my complaint. 
Look at all of the extra, unused space created by the height of the application logo. They clearly had the room to extend the row to accommodate the wrapped application title. I'd rather have the extra space under the icon than under the text block - especially since I can't read the entire application title as it is. |
|
|
Wednesday, 17 March 2010 14:55 |
|
For this installment of my What Were They Thinking series I’m going to pick on Research In Motion. Considering that they invented the whole smartphone market, they’re usually pretty good about designing BlackBerry applications with forethought and an attention to detail. After all, they created the platform and they’re responsible for maintaining consistency across all applications. Right?
I was browsing through the list of free applications in the BlackBerry App World application yesterday and was struck with how hard it was to read the application names in the list of free applications. See the figure below for an example of what I saw:
 When building a mobile application, you have to pay special attention to first of all how much data is delivered across the wireless network and how much work the application has to do to process and render the data. This is wireless application 101 stuff.
When you look at the application list, you’ll notice that they’ve designed the application so you can see the application’s icon (useful for branding purposes) but only a portion of the application’s title. I don’t know about you, but I can’t tell what the application names are for these applications.
On top of that, take a look at how much screen space is taken up by the word ‘Free’ for each application. We already know it’s a list of free applications – if we didn’t remember that when we looked at the screen, we could have easily been reminded by looking at the ‘Top Free’ in the title bar. There’s no need to show the word ‘Free’ for each application – they’re all free. It’s extra screen space that could have been used to allow more of the application name to display.
Since I can’t read the full application name, I have to open each application to learn what the app name is – bad use of my time. There’s also absolutely no reason why the application title can’t wrap around to the next line. Who cares if it takes up an extra line on the display? If you look closely at the screenshot, you’ll see that there’s wasted space anyway underneath the application vendor name. They didn’t try to scale the application icon to the available space used by the application title and vendor – what they should have done was kept the icon the same size and adjust the font sizes to allow three lines of text for the application title and vendor.
Which is more important, making it easy for the user of the application to be able to read the information on the screen or keeping all rows the same height? I’m hoping you will agree with me that the user is more important here. I don’t mind if I can’t read the whole vendor name, but I do mind that I can’t tell what the application’s name is.
What were they thinking? |
|
Monday, 15 March 2010 08:00 |
|

I've gotten involved with the View Domino Admin/Developer Conference again this year. The 2010 conference will be held in Boston (as usual) and runs from May 12th through the 14th.
For this year's conference, I'm doing my Domino Rich Client application session I did last year at the conference and also this year at Lotusphere. Of course I have to change it up a bit between each session. In last year's View conference, I showed how to build a Domino Web Service (the same web service I've written about here) then how to build a BlackBerry MDS Runtime application that talked to the service, a BlackBerry Java application and a Windows Mobile application.
MDS Runtime has since been end of lifed by RIM (December 31, 2009), so for Lotusphere I pulled MDS Runtime from the presentation and did BlackBerry, Windows Mobile and tried to get Android done in time for the conference, but wasn't able to show a completed application. I had a horrible time with some of my demo's, everything crashed but I was still able to show everything (because every good presenter has a back-up copy of everything ready to show).
For this year's View conference, I've finished the Android version of the application (it's pretty cool and I learned an awful lot about Android in the process) so I'll be showing that along with the BlackBerry application. I was thinking of also showing the Windows Mobile application again, but I'm just not sure people really care about it. With the forthcoming Windows Mobile 7 breaking every previous version of the application, the Jury's out as to whether I should still show it. Let me know what you think. Even though the slide decks are due today, I'm planning on spending the rest of the time between now and the conference building the same application for the iPhone. I'm going to first do the development using XCode and Objective-C but hopefully I'll have time to build a browser-based application as well using DashCode. We'll see what happens and how much time I have to throw at this.
As I promised after Lotusphere, I will be publishing an article about how to build the Android application here (with source code).
I'm also doing a session entitled "Current Trends in Mobile Application Development" where I'll be talking about the current trends in mobile application development ;-).
I've also taken a position as a Technical Advisor to The View publication. I'm going to be focusing on mobility related topics and hopefully penning some articles for the publication. Stay tuned for more information.
|
|
Tuesday, 09 March 2010 20:30 |
|
A colleague asked me a while back to provide my comments on InfoWorld’s Enterprise iPhone Deep Dive Report. I found it to be an interesting read and I was convinced when I finished that you should never allow a bigot to write an article if you’re going to pretend that you’re impartial.
I could be wrong on this, and as usual my comments below do not reflect the official position of AT&T, but here’s my take on the report:
I’m not sure the iPhone is capable of satisfying the enterprise and the different articles in the report highlight many of the issues, but not really the root cause behind them. Apple historically has never really ‘understood’ the enterprise and until now it hasn’t really been an issue. Now that these organizations have all of these remote devices accessing corporate data, it’s even more important that Apple understand the enterprise. Buried deep within the report was the following statement:
“Apple designed the iPhone as a consumer device, so it’s heavy on convenience and light on security. If you want protection, you have to accept some pain”
No enterprise is going to be interested in hearing that unless they’re willing to forgo security in order to have the cool device (which is currently the case with many enterprises).
If you think about the platform, it was designed under the premise that users would not run any application other than the applications provided by Apple or a select few of very trusted partners. The web browser, being a desktop browser in a small package rather than an actual mobile browser, was deemed to be sufficient for all user needs. The tradeoff they got by making this assumption was that they could build the platform allowing all applications to run with root level access within the Unix security model. They wouldn’t need a security model since they weren’t planning on allowing anything but their applications to run. All applications run with the same level of access and each and every application can do anything it wants to anything else on the device. No sandboxing, no varying levels of access (Apple applications running with the most access, other applications running with less), nothing. Everything runs as root. No system administrator on any unix system in the world would allow that for any end user computing device, but that’s what Apple did with the iPhone.
After Apple decided that end-users did want to have access to applications, Apple quickly ‘patched’ the environment to allow third-party applications. They took a system designed with no security and added a security model (of sorts) on top of it. Now, third party applications could be created and Apple reserved access to some API’s for itself – most likely over security or performance concerns. What I believe, unless Apple has done a complete rewrite, is that the iPhone platform doesn’t have the foundation enterprises need to feel that the device is secure in their environments.
I believe that Apple’s prohibition of background applications is another offshoot of this design. Since they didn’t build the necessary security restrictions in the original platform, they have to worry about applications running in the background, gaining access to all sorts of information and data the enterprise would otherwise not want accessed. By not allowing background applications, they can avoid any security concerns over inter-process communication.
Apple’s getting there with regards to support for ActiveSync policies. More and more policies will be added over time. What’s clear from the article is that if you’re on ActiveSync, many of the enterprise security features you need are there and I believe more and more will continue to appear with each release of the platform. If you’re not on ActiveSync, then your choices for enterprise management are:
1. Buy a third party product 2. Use the free tool Apple offers, the iPhone Configuration Utility
The problem with the iPhone Configuration Utility is that while you have the ability to configure all sorts of settings, there’s absolutely no way to ensure that these settings are deployed and correctly maintained on the affected mobile devices. None. The user has to act to implement the security feature you have created for them. Enterprises security departments will not accept that as an option. The report later says:
“But a big IT issue remains: you can’t easily manage iPhones through a central console wirelessly, even though you can do some management (profiles and remote wipe) via email, the web and/or Exchange 2007. IT Pros rightfully complain that Apple essentially forces them to use a local PC as a management workstation and physically connect user’s iPhones to it”
The conclusion correctly reached in the report is that ActiveSync good, anything else bad. Since the majority of enterprises are running Exchange, most organizations should be OK.
There’s still the issue where any iPhone prior to the 3GS would report to ActiveSync that it was capable of encrypting or was actually encrypting the local data when it actually lacked the capability it said it had. That’s got to have many enterprises scared to death and I’m waiting to see what lawsuits make it into the courts over that one. Take for example the Massachusetts law that goes into effect in March requiring any organization to encrypt data regarding any Massachusetts resident any time it’s stored:
http://www.27001.com/massachusetts-data-protection-law.aspx http://www.mass.gov/Eoca/docs/idtheft/201CMR17faqs.pdf http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1347836,00.html# http://www.alertboot.com/blog/blogs/endpoint_security/archive/2009/01/06/massachusetts-data-encryption-law-201-cmr-17-00.aspx
In the case of the iPhone, enterprises would believe it’s encrypted and they’re in compliance with the law when on older iPhones it won’t be the case even though the device is saying it is. Not good for enterprises.
I learned a little from some other topics in the report. I’ve always wondered why Apple forces everyone to go through them for application approval. I always thought that developers should be able to do whatever they want on the platform. That won’t work for Apple. Since the fundamental security platform isn’t there, Apple has to analyze and approve all applications because they have to make sure that the application isn’t doing anything it’s not supposed to be doing. What was most telling was Apple’s prohibition of downloading any code from the internet. Apple even forced one vendor to remove the eval function from their JavaScript library. This is because a developer could download dangerous code and execute it within the context of the application – without the needed security model, Apple can’t allow it. The BlackBerry and Android platforms can both allow this ‘feature’ because the requisite security features needed to protect the user and/or enterprise were built into the platform from the very beginning.
The last thing I noticed was that several of the articles were laced with inaccuracies. It’s clear that the authors are enamored with the iPhone platform and didn’t take the time to validate the things they said about the other platforms. I was able to update the author that indicated that the BlackBerry platform supported WebKit in newer devices (not true) but the iPhone vs. BlackBerry article was chock full of falsehoods and it’s clear that the author didn’t care about being accurate. |
|
Monday, 08 March 2010 15:35 |
|
Just got my Motorola Backflip. So far I like it. It's a consumer device, but has support for corporate email and policies. I'll be playing with this over the next couple of weeks and I'll write a review. I'm really excited about the device - all signs point to Android exceeding the iPhone in the Enterprise Market (which is where I work).
Here's a couple of things I learned as I played with the device for a few minutes:
MotoBlur is pretty cool. In a matter of minutes I had my account created and setup Twitter, Facebook and personal email. Limiting that you can only define one Twitter account (I have two). Supposedely MotoBlur provides better Exchange ActiveSync support than what is available in Android 2.1.
The device has a touchpad on the back of the screen. When you're holding it open in your hands with the keyboard exposed, you can navigate the screens by swiping on the back of the screen. The front is a touch screen, but the back gives you a different sort of navigation. Different. Interesting. Time will tell how useful/fun this is or how much it enhances the usability. |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 5 of 24 |
|
|