John Wargo

I'm a big fan of Robert X. Cringely (although lately he's gotten a little flaky) and I was just reading an article he wrote called 'Pictures in our heads' that discusses the future of mobile computing from a very interesting angle.

He points out that desktop computer sales are about to peak (I believe that, but I still love having a honking fast desktop) and shows how mobile devices are advancing at a faster pace than PC's or laptops.Of note was his comment:

"This means that mobile devices are evolving twice as fast as desktops ever did.  This just about equals the rate at which wireless network bandwidth is declining in price and matches, too, the faster-than-Moore’s Law growth of back-end services."

and

"Now just imagine what it says for the smart phones to come.  In another two years they’ll be eight times as powerful as they are today, making them the functional equivalents of today’s desktops and notebooks.  If only we could do something about those tiny screens and keyboards."

Having just taken a position withing AT&T and being involved in emerging technology, I'm going to be very interested to see what happens in the next few years. My colleagues at RIM ridiculed me when I said people would be embedding bluetooth headsets into their heads so they would not need to hold a device up or could listen to music whenever they wanted - only time will tell if I'm right although I'm pretty sure it will be here soon at least for younger generations.

As the smartphone app stores become more prevalent and of course all of the app pressure from the iPhone, more and more developers are trying to create these really beautiful and really feature full applications. Apple has done this to all of us and it flies in the face of how you should really build mobile applications.

The smartphone has limited battery life, limited processing capacity, limited memory and limited network capacity available to it. It does, it really does – but were being made to believe none of those things are important because of the way all of these apps are being made. A smartphone application, or at least an enterprise smartphone application, should have as few bells and whistles as possible – the application should be crafted so the application is at least good looking, easy to use (without requiring an instruction manual or training) and the user has access to the exact data they need, when they need it and nothing more.

Smartphone applications should work regardless of whether a network connection is available or not. If can have less functionality when disconnected, but it should continue to work – using the locally cached data available to it.

I’m at the BlackBerry Developer Conference in San Francisco this week (look me up if you’re there – my published will be selling copies of BlackBerry Development Fundamentals and I’m going to be signing copies of my book at the conference Thursday during lunch) and before I left I installed the free conference RIM provided for attendees. I expected RIM to use the Viigo application again like they did last year, but instead I found that they apparently engaged someone else to build this year’s conference application. It’s too bad, because the Viigo application is pretty cool and has usefulness outside of the conference and this new conference application is pretty horrible. The application is however a great example of how you should NOT build Java applications for BlackBerry devices. Let me explain…

The application is installed from the BlackBerry App World which is cool and is what I would expect from any mainstream BlackBerry application released in 2009 and beyond. It’s when you go into the application that you notice that the people who developed the application really didn’t know what they were doing. The application wasn’t crafted for a mobile user to use at the conference; it was crafted to show off the cool capabilities they have built into the application.

When you first launch the application, a splash screen fades in (showing the conference logo), sits there for a while, then fades out again. If I’m an attendee at the conference and I’m trying to look up something (like where I need to be next) this long delay in opening the application just to show me how you can make a cool fade-in effect is a waste of my precious time and places an extra drain on the battery. Think about it, I’m at a conference going from session to session sending emails, making phone calls and generally using my device heavily. On top of that, with the expected 1,000 people at the conference, it’s likely that cellular wireless network coverage is going to be in high demand. I don’t know if you knew this, but the BlackBerry device (and most smartphones) drain their battery at a more rapid pace when it has difficulty getting or keeping a wireless network connection. So, as I’m sitting at the conference draining my battery at a higher rate because of an overloaded local network, the application is shamelessly wasting even more battery life. Now, don’t get me wrong, wi-fi should be available, so I’m not worried about data traffic – but when the voice network gets congested (as I expect it will) batteries start to drain.

OK, when the splash screen finally fades away and I can get into the application I’m presented with the screen you see below. They’ve selected a VERY busy background and used these battery wasting scroll-in effects for the menu so it takes even longer before I can begin working in the application.

As you scroll from menu item to menu item, the application uses this smooth fade-in ad fade-out for the selected menu item then changes the entire background image (as shown in the following figure).

OK, so not only do I have a very busy (too busy) background image for the application, I have to wait as the application applies fancy effects to the menu and swaps out the complete background for the application. Yet another waste of my time and a huge waste of device battery life.  Developers should not add screen effects that slow down application performance for the user. If you can implement them without affecting the user, great – otherwise leave them out of your application.

I’m an older guy and my eyesight has been deteriorating lately (not too bad, but enough to be annoying) and the dark menu against the busy background makes it very hard for me to be able to read the screen without my glasses on. Developers should always pay attention to how the background affects readability and usability for the application. Complicated or busy background images just don’t belong in any mobile application.

Notice by the way that in the pop-up menu (the menu you get when you press the BlackBerry menu key) the option for ‘Configuration’ is misspelled. I’m assuming this is because the application was created by one or more developers for whom English is not their primary language. Any time you build an application that will be consumed by others, you have to make sure you spell check all of the menus, field labels, help pages and content.

For the first couple of times I tried to select anything, I went past the menu item I wanted because it was so unresponsive. When you’re finally able to get to the menu item you want (I’m serious, it’s very, very slow on my BlackBerry Curve 8900) and you’re looking at content, the developer did not follow RIM’s standards for BlackBerry applications. Let me give some examples:

• When reading content, some of the standard navigation keys seem to work (such as ‘t’ for top and ‘b’ for bottom) but you cannot press the space bar to page through content. So, experienced BlackBerry users, ones who know how to quickly get to the content they want, won’t be able to use standards they already use in other applications.
• The BlackBerry menu button is disabled in all of the content screens (about, event listings and more). So, if you are used to switching applications using the menu, you’re out of luck. If you want to select some of the content to paste into another application, you’re out of luck. If you want to invoke some third party menu item (like the screen shot capabilities of BoxTone Expert) you’re out of luck.
  Developers should ALWAYS build their BlackBerry applications so they work like every other BlackBerry application or at least all of the applications that come with the BlackBerry. Omitting standard features like keyboard shortcuts and the BlackBerry menu is a serious crime when it comes to BlackBerry applications.

When looking at the about screen, the developer used some sort of special library to make the content scroll very smoothly. I’m sorry, but that’s just not needed – the BlackBerry platform provides a field you can use to display content and the BlackBerry device manages scrolling the content for you (including I believe allowing you to use the space bar to page through the content). Adding addition capabilities to an application that are already provided by the core platform is a waste of memory, processing time and battery life. There’s no need for special stuff like this, all it does it make it take longer for me to be able to page through the content (it’s so busy making the scrolling smooth that it’s slower than it would be otherwise).

When you look at the content on screens, the developer did not make any effort to match the application’s fonts to how I have the device configured. As I mentioned earlier, I’m a little older and I need a larger font. I’ve set the BlackBerry screen options to display text in a size that allows me to read it without digging out my reading glasses. In this application, the developer has selected the font size and I find it very hard to read. If I go to the Configurations (that should be Configuration, but they forgot to check spelling) screen, there’s no option for setting the display font. Developers building applications should pay attention to what settings the user has for Screen and Display options and act accordingly. Deciding for me what screen font size to use would work for many users, but for those of us who don’t wear glasses all the time but need help, the application is all but unusable.

Take a look at the application’s configuration screen; I don’t understand why developers feel the need to build special screen elements for configuration screens. This one is just like the main screen, a slow and unresponsive menu system that doesn’t add any value. Why not just make a simple screen with the appropriate fields? Why take up the extra memory for all of these extra features? Why kill the battery life by forcing the user to go through all of these custom menu and field animations when the ability to have normal, everyday fields is built into the platform?  In later versions of the BlackBerry Device Software, RIM added the background factory which allows developers to easily place a screen or field background in their applications – there’s no need for all of this extra junk – it adds no value for the end user, all it does is allow the developer to show off and it’s just wasting my time (and battery performance).

The developer of the application is Sweet Caesar Inc (http://www.sweetcaesar.com/) – I’d suggest that they spend a little more time making their application usable and less time making it pretty. There are going to be 1,000 people in San Francisco this week cursing their product every single time they use it. Not a good thing for a company’s reputation.

I don’t know why I like writing about these Internet email scams, but I just do. I think it’s because I know people are responding to them (otherwise they would go away) and that just fascinates me.  Here’s one I got this morning – it’s so stupid that I’m stunned that anyone would even try this approach, but you know what P.T. Barnum said, right?

Here’s the email I got:

The good thing is that my ISP recognized the email as Spam (no, Spam is not an acronym, it’s a breakfast meat product – why do people type it in all caps?) and modified the subject of the message on its way to me. Anyone receiving this should benefit from those types of services that ISP’s provide. 

I forgot to look at the message headers before I deleted the message. If I’d been smart and thought to do that, I’d be able to show you the actual email address behind the email message. It’s always a good idea to look at the message headers of any suspect email – it tells you a bit about where the message really came from and what route it took to get to you. Any message from Facebook that started in some Eastern European country is suspect no matter what. Not because Eastern Europe is a dangerous place to get emails from, it’s just that Facebook is a US company and it’s likely that any message they send me will likely come from a US Server. Right?

Now let’s look at the email address it was sent to: info@mcnellysoftworks.com. Well, I happen to know that I don’t have a Facebook account registered using that email address. That’s my next clue that it’s junk email. 

The subject of the email makes sense, nothing too scary there (except for that SPAM notification my email server added to the message).

The body though, just isn’t right. I have to think that if Facebook is sending me email messages, they’ll take the time to:

1. Make sure it looks professional. I’m pretty sure the Facebook logo will be in anything they send to me.
2. Address it to me. They know my first and last name, any message from my bank, amazon.com, facebook.com, linkedin.com and others better be addressed to me by name otherwise I’m ignoring it. Why would they say ‘Dear Facebook user’ when they could just have easily have said ‘Dear John’?
3. Make sure it’s in English. I don’t know about you, but ‘Accounts that do not submit the updated account agreement by the deadline will have restricted.’ Isn’t a complete sentence and was probably written by someone who doesn’t use English as a first language.

Now, here’s where it gets interesting. So Facebook is a very popular, Internet-based Social Networking site, right? Everything (and I do mean everything) they do is done online, right? So, why would they send me a zipped attachment containing an account agreement? Nope, they’d never do that. Take that a step further and ask yourself, not only would they not send me an attachment, they also wouldn’t ask me to launch an executable to access the agreement. If, by the wildest stretch of the imagination, Facebook did send me an account agreeement as an attachment, woudn’t you think the the attachment would be a text file, a Adobe Acrobat file (.pdf) or even a Microsoft Word document (.rtf, .doc or .docx)? It’s an absolutely rediculous premise that people would think it’s OK to unzip and attachment and execute an executable (I know, redundant) to access an account agreement for the world’s biggest Internet site?  Seriously?

Anyway, I think it’s funny that these spammers and scammers are still trying this approach. But, as I said at the beginning, they only reason this would still be happening is if either the scammers are really, really stupid or people are actually following the instructions and launching the attached executable. It has to be the latter and that just scares me.

I use Joomla! to manage many of the sites I’ve built. It’s an open source CMS and it’s really pretty cool. As I was building blackberrybooks.org yesterday I made a big mistake and thought I’d write about it.
I host all of my sites on fatcow.com, they’re really great and have some amazing tools site administrators like me can use to manage their sites, install open source tools, create databases, create mail accounts and more. One of the tools is something called InstallCentral that basically points to scripts that can be used to install all sorts of open source tools (content management systems, blogs, galleries, forums, e-commerce stuff and more). It was through this tool that I first discovered Joomla! and although Joomla! is pretty easy to install, I’ve always just let FatCow’s InstallCentral install it.

Anyway, yesterday I was working on setting up blackberrybooks.org and I launched the installation like I normally do. When it came time to pick the installation folder, I accepted the default and populated the other fields on the installation form as shown in the following figure:

What I forgot to pay attention to was that www.mcnellysoftworks.com actually pointed to a subfolder called ‘home’ within my FatCow account. That way I can have my ‘home’ folder and a separate folder for each of the other sites I manage there. So, when InstallCentral installed Joomla!, it dutifully put it exactly where I asked it to be placed and that was ‘/home/bbbooks’  which is not where I wanted it, I wanted it in a folder called ‘/bbbooks’ off of the root.

After I got the site all up and running and populated all of the book information, I used another cool FatCow tool called ‘Domain Pointing Manager’ to point www.blackberrybooks.org to the folder where I thought I’d installed the site. When I fired up the browser to test the redirect, I got a file not found error message. I quickly fired up an FTP Client (I use FTP Voyager http://www.ftpvoyager.com/ from Rhino Software) and looked for the folder and it wasn’t there! Ouch. I looked and looked and looked and could not find the Joomla! files where I thought they were supposed to be. It took me a while to figure it out but I finally did and located the files – right where I didn’t want them but right where I’d told the installer to put them.

Rats, what do I do?

Well, I couldn’t tear down the site and reinstall then rebuild in the correct location (I know how I’m supposed to do it, I just forgot to do it) but on principal that didn’t make sense to me. I hate completely redoing something – it’s just not in my nature.

I thought perhaps I could just use FatCow’s File Manager application to move the files, but I thought perhaps it would somehow not work once I got it moved. Also, I didn’t want to have InstallCentral thinking it had an installation where it didn’t (my form of OCD) so I couldn’t do that.

As I thought about it I was suddenly struck by a thought. On a weekly basis I backup all of my sites using JoomlaPack (a free backup utility for Joomla!)- I wondered whether I could use that to backup the site and put it in a new location. I dug out the instruction manual and found to my delight that I could.

So, I performed the following steps:

1. Backed up my Joomla! installation for the site
2. Copied the backup file to my local hard drive
3. Unzipped the backup file to a temporary folder
4. Uploaded all of the site’s files to the /bbbooks folder on my FatCow account
5. Launched the browser and accessed the site in its new location

It worked!  Woohoo, it worked! So, I now had the files where I needed them and it was working. One of the reasons it was working was that both instances were using the same database table. I knew though that as soon as I uninstalled the Joomla! instance created by InstallCentral it would empty (but not remove) the existing database. Well, that wouldn’t work – when I uninstalled it, I would lose all of my data. So, I went back in and performed the following steps:

1. Performed a database backup (because when I uninstall the Joomla! instance, InstallCentral will drop all of the database tables)
2. Uninstalled the Joomla! instance in InstallCentral
3. Restored the database from my local backup

Who’d a thunkit, it worked!!! I got the whole thing moved and the InstallCentral installation list all cleaned up and it’s working great.

I know, I know, I could have used the FatCow File Manager application to just copy the files to the new location then do the second set of steps, but it was fun to see whether JoomlaPack would do what it was supposed to do (I expected it would, but it was fun to find out).

I wrote this article to help others playing with FatCow and Joomla! but probably also to reinforce in my mind that whenever I install another Joomla! instance using InstallCentral, I need to select the Unix root folder name for my FatCow account rather than the high level domain as shown in the figure.

I worked on a project a long time ago with a guy by the name of Russ Chung – he was the most meticulous tech guy I’ve ever worked with. Whenever he worked through a problem on the Domino server, he would speak all of the steps as he did them (almost a monologue). The result was that he took his time and walked through all of the steps as he was doing them. I know that if I’d taken the time to think while I did the initial install (like Russ would have done) then I could have saved myself all of this work (as fun as it was).