Healthcare and Mobile Process Enablement

March 15th, 2010

Yves Neidlinger:  National Channel Sales & Marketing Manager

I just returned from my 3rd HIMSS conference and lucky for me, it was on home field turf in Atlanta. For the uninitiated, HiMSS stands for the Healthcare Information and Management Systems Society. Think of it as a massive trade show relating to all things technology and healthcare.

Last year, I wrote about the growing trend of healthcare and mobility blog post: http://www.navara.com/blog/healthcare-and-mobility  and I’m happy to see that more vendors are realizing the market potential for mobile solutions. Not too long ago, I would commonly hear companies question the value of mobility, but those doubts are long gone. Today, the biggest concerns are which platforms to support and how to create a compelling mobile application that meets the needs of its users.

Ten years ago, the mobile device landscape was much simpler. You either were in the Palm or Pocket PC camp. Blackberry was just coming into the scene and other devices such as Psion and Sharp’s Zaurus had already seen their heyday. Today, the mobile device market is much more diverse with Blackberry, Windows Mobile, iPhone, Android and to a lesser extent, Symbian. Let’s not forget the burgeoning tablet, netbook, iPad market.

If you were an ISV (ten years ago) your choices were very simple, you developed your mobile application for Palm and/or Windows Mobile. Today, most organizations are too resource constrained to develop for each commercially available platform. What’s a software developer to do?

Enter Mobile Process Enablement. If you’re scratching your head, saying huh? I’ll explain.  MPE is the acronym for middleware solutions that allow for the rapid development of mobile applications that tie into existing databases.  In other words, they provide a quick way to develop a mobile app that is an extension of a desktop or cloud application.

The rational for leveraging an MPE solution is that with minimal development resources a developer can offer their application onto a variety of mobile devices without having to worry about building proprietary applications that must be constantly maintained and supported. Oftentimes, a mobile middleware platform can save about 90% of the development and support costs.

Did that get your attention?

The Ambiguous Interface of Mobile Applications

March 1st, 2010
The Ambiguous Interface
We often tout the GUI as the most important design feature in software.  It makes sense; it is the most visible part of any software product.  But how important is the interface to the overall success of a product?   I’ve seen excellent products that have absolutely horrible interfaces – and here’s the thing:  they still sell.  An excellent product is one which fills a need, and companies will purchase it if it does the job – pretty or not.  The problem is that those needs change, and when they do it typically has been expensive and cumbersome to adapt a product to fit those changes.
We Humans are capable of learning new interfaces fairly quickly. Consider the slight variations in telephone keypads – how long does it take us to dial an unfamiliar telephone?  How difficult is it to use an unfamiliar automated cash machine?  How quickly do we learn the shortcuts for a new mobile phone?  Certainly these examples cite both excellent universally acceptable design practices but also our ability as humans to adapt and learn new designs easily.  More interesting – I propose it takes the average person less time these days to learn an unfamiliar interface than it did 15 years ago, and I attribute this to the fact that we are presented with new interfaces much more frequently now than we ever have been before.
Case in point:  Video game controllers have come a long way in the past 15 years.  Atari’s now-nostalgic one button joystick interface bears no resemblance to Microsoft’sXBox 360 ergonomic controller with it’s astounding 25 buttons.  Every year another new interface is presented, normally around the time that Santa Claus requires his wish list, and the next plastic race car wheel or wireless band instrument is marketed to eager consumers hungry for a new interface to master.
In business software, the same issues occur.  Interfaces grow and change throughout the system life cycle.  With time, all interfaces must adapt to support increased functionality – or just as likely increased marketability!
This prospect was once expensive and cumbersome for mobile software, because of the complexity and unique resources required to develop for these relatively obscure platforms. Navara partners use the Navara Design Center to quickly and visually create and modify interfaces for the most popular mobile platforms, so the interface can easily change as the users’ needs change.  So when the next change comes depend on Navara, and let’s solve the interWe often tout the GUI as the most important design feature in software.  It makes sense; it is the most visible part of any software product.  But how important is the interface to the overall success of a product?   I’ve seen excellent products that have absolutely horrible interfaces – and here’s the thing:  they still sell.  An excellent product is one which fills a need, and companies will purchase it if it does the job – pretty or not.  The problem is that those needs change, and when they do it typically has been expensive and cumbersome to adapt a product to fit those changes.

Bill McDaniel: Navara Software Engineering

We Humans are capable of learning new interfaces fairly quickly. Consider the slight variations in telephone keypads – how long does it take us to dial an unfamiliar telephone?  How difficult is it to use an unfamiliar automated cash machine?  How quickly do we learn the shortcuts for a new mobile phone?  Certainly these examples cite both excellent universally acceptable design practices but also our ability as humans to adapt and learn new designs easily.  More interesting – I propose it takes the average person less time these days to learn an unfamiliar interface than it did 15 years ago, and I attribute this to the fact that we are presented with new interfaces much more frequently now than we ever have been before.

Read the rest of this entry »

NL: Nieuwe ontwikkelingen binnen Navara; een technisch kijkje in de keuken…

February 22nd, 2010
René Zeldenthuis

René Zeldenthuis:  Software Developer

De hoeveelheid data neemt steeds maar toe en we willen steeds meer data offline tot onze beschikking. Te denken valt aan het op het mobiele toestel beschikbaar hebben van een postcode database of misschien wel het gehele klantenbestand. Dit heeft automatisch ook tot gevolg dat de hoeveelheid data die wordt overgestuurd groter wordt; dit is eenmalig. Nog interessanter wordt het om de gegevens allemaal actueel te houden en dit op een zo slim mogelijke manier te doen. Het is nu eindelijk zover; alles is doordacht; de specificaties zijn klaar en een compleet nieuw synchronisatieprotocol wordt momenteel geïmplementeerd!

Wat er zo vernieuwend is aan dit nieuwe protocol zijn de volgende vier hoofdbestanddelen:

  • Slechts veranderingen worden doorgestuurd. Hierdoor is het niet nodig om bij een wijziging (van bijvoorbeeld één postcode) de gehele database over te sturen. Ook is het niet meer nodig om een referentie van de aanwezige gegevens over te sturen naar de server.
  • Bij het verbreken van de verbinding tijdens het synchroniseren kunnen alle gegevens dusver ontvangen toch worden verwerkt; het protocol is geheel ‘restartable’.
  • Er wordt gebruik gemaakt van http/https. Hierdoor gaat dit nieuw protocol door de aanwezige proxy servers en deze poorten staan mestal open in de firewall. Verder is het https protocol (dat bijvoorbeeld ook voor telebanking wordt gebruikt) tegenwoordig standaard voor het versturen van gevoelige data.
  • De Navara client bilijft altijd verbonden. Indien er gegevens worden ontvangen die relevant zijn voor de client worden deze direct doorgestuurd (push). Ook worden gewijzigde gegevens van de gebruikers direct teruggestuurd. Uiteraard worden deze gegevens opgespaard indien er geen verbinding mogelijk is en deze direct verstuurd zodra dit weer mogelijk is.

Uiteraard is het wel nodig dat er gebruik wordt gemaakt van een nieuwe client en server dit dit protocol kunnen ondersteunen. Dit zal even lastig zijn maar hierdoor wordt Navara nog sneller, veiliger, rubuster en actueler!