Ninas Travel App: Today and Tomorrow

August 9, 2016; September 10, 2016 - Rolf Eckertz

As I sat again in front of the PC and programmed, my daughter asked: "What are you doing there?" - My answer: "I have decided to switch to JavaScript, because then I can program apps for Android, iOS and Windows 10 , I can program browser applications, I can program a node.js backend and I can program technical applications on Raspberry Pi - with isomorphic code, no-SQL databases and an asynchronous programming model " - " How boring, can you just write an app that supports me in Work and Travel? " - And that way Nina's Travel app was born - for work and travel. The requirements and an initial design were quickly formulated and designed by Nina  - and I had to hurry regarding her travel schedule. Meanwhile the first release is finished and in use and there are many ideas for enhancements.

diary - requirements for the first release

• Fast rating for mood, health, weather with emoticons
• text entry 
• GPS-Location if available
• Entries of revenue and expenditure
• Time data collection for work-hour

The following requirements will be covered by other solutions:

• Photos are stored separately
• Contacts are maintained separately
• Calandar entries and alerts are covered separately
• travelling and route planing is supported by other, specialized apps

From my background as developer of solutions for life science industries I am accustomed to compliance oriented development. So the following aspects technical requirements are covered too

• Privacy - diary data can be very personal, so protection of the data and the correspoinding inquiry functions against non authorized users is a key requirement
• Consistency - the data may not be manipulated or deleted by other people
• Security - the data collected in the app is additionally stored on a server as backend with automatic synchronization

To program and deploy these functions the following technologies have been used:

• Intel XDK with extensions
• Cordova
• Cordova Plugins
• jQuery
• jQuery Plugins
• jQuery Mobile
• jQuery Mobile plugins
• isomophic code
• Modularization
• IndexedDB
• Microsoft Visual Studio Code with extensions
• Node.js
• MongoDB
• Red Hat Cloud with OpenShift
• GIT

A first release  - honestly more alpha than beta - has been developed and testet - and like always in the life-cycle of a product there are new requirements and ideas:

• enhanced UI
• multiple text entries per day instead of only one big entry per day
• only one record per day with all the entries of that day
• granular granting of strict privacy  - these diary entries cannot be read by other people
• display of calendar entries for the actual day (only on smartphones)
• direct entries to the "diary calendar"
• reminder for "diary calendar" entries
• protection of diary entries for days in the past, no changes and no deletions - but additional data can be entered
• general feedback for system-actions to the user in the footer of the app
• system-reaction to suspend-events and resume-events
• automatic execution of synchronization with future entries where the server is available  in case the server was not available when entries where done and stored locally in the past (manual synchronization is not convenient enough for users)
• Export to eMail with pdf attachment
• Export to pdf 
• Integration of camera
• direct integration of camera
• integration of access to photolibrary and saved photoalbums
• integration of barcode-reading with the camera
• data-collection for books with ISBN
• data-collection of other goods
• Integration of speech to text, speech-recognition
• realtime push-services
• enhanced security and data protection
• secure communication with https
• user administration
• device administration and check of devicetype
• Login with user, password and captcha regarding special functions
• session management
• grant reading rights to other users
• encryption of datacommunication
• encryption of data-storage in the server 
• enhanced technologies and new Technologies
• dynamic updates with javascript-modules from the server to the app
• uniform usage of jQuery-AJAX - modern way
• analyze and document metadata for database, collections, indexes, structures
• automatic translation, multilingual capability

That's in fact a lot to do - it will take some time and most of the points will be programmed one after the other. The plan is step by step - code a little, test a little.

The biggest pain points have to be solved first:

• Updates so far are complicated and loss of data has happened
• the manual synchronization of data is too complicated, that has made the loss of data problem more critical

So the first steps to do are:

• secure login and session management for all users and administrators regarding the browser-usage - the co-reader functions are a must too, that means secure sharing of diary data
• automatic software update without reinstalling the app with check, when Ninas Travel App is activated and the server is online - this is very sensitive regarding security
• automatic data synchronization with check when Ninas Travel App is activated and the server is online

But my daughter meanwhile has changed her mind: a browser based solution is better for entering more text into the diary - and that's what she wants now, so priority 1 is now bringing the diary entry to the browser and priority 2 are the security issues.
September 3, 2016 - the actual state:

• entry-panel is transferred from app to browser
• access to indexedDB is eliminiated - finished
• AJAX-requests for storage were already programmed as backup, it is reused
• AJAX-requests for inquiry were already programmed, they have been extended - finished
• usability and layout are changed a bit to better support big screens - finished
• change to one diary-record by day - finished
• change to one record by day in scrolling - finished
• exclusive read and write data according to the user - finished
• add enhanced features - later
• user-administration - finished
• secured login - finished
• additional captcha - open
• protection against url-, path- and hash-overwriting - finished
• session management- finished
• clientside inactivity control and session-refresh - open
• session-storage - finished
• login logging - finished
• browser-logging - finished
• uniform messages to the user in footer - finished

The "next steps" depend on the actual priorities. At the time:

• merge diary entries from browsers and apps - finished
• no data is deleted
• merge tries to avoid redundant data
• co-reader functions to browser-UI
• Invite other users as co-readers to your diary
• enter invitation in the diary application
• the other user must already be registered as user and have an email-address
• there is no search function against the diary-users, because the information that someone is using the diary is secret. Sharing of information has to be negotiated and prepared outside of the diary system
• send system generated invitation to potential co-reader by email
• the receiver of the email can register as co-reader to a diary
• click on link in the email or copy the link to the browser url
• registration is done automatically
• afterwords the login screen is envoked for the co-reader, for security reasons he has to do the login himself
• the co-reader has a flyin menue with a list of all the diaries he may read
• availability checks and optical indicators for availability
• server-connection
• GPS-availability
• as colored icons in the footer
• enhance UI with fly in menues and popup-panels
• protection of diary entries against changes, display in read-only mode
• automatic translation
• of UI labels
• of UI messages
• of diary entries (Text)
• a good candidate seems to be https://msdn.microsoft.com/en-us/library/ff512385.aspx 
• de to en - German to English
• profanity filtering may be a good approach to encapsulate text that shall not be translated, like product names or certain technical expressions or technical error messages (encapsulation is done by the xml-tags <profanity> and </profanity>).

After these enhancements to the browser the app will be upgraded to the new user- and security features:

• new login and user registration
• add security features
• new health check page
• extended dialog to enter diary data - reuse code from the new browser solution
• extend storage in local indexedDB
• extended data-exchange to the server as backend
• automated data-exchange (synchronization) with the server
• automated software update from the server

A lot of work.

After that "devops"-support will be added:

• list of all active users
• push messages to all active users regarding updates or downtime

Regarding framework and tools it's the time to start. The basic functionality is tested and stable, so routine programming can be substituted by code generation. A first approach has been programmed some months ago and now the knowledge base is better.

I'm aware that jQuery Mobile is under discussion regarding the future. Nevertheless my experience has shown, that even very big players can decide product changes very fast - so size is no guarantee of stability. And jQuery Mobile is stable and so far sufficient to develop for the browser and for hybrid apps - so what.

Ergonomic optimization of data entry is not that easy, controlgroups and fieldcontainers resp. fieldsets are not as expected regarding hoziontal alignment of multiple input fields. "Keep native" may be a good approach. Box sizing with tables and input seems to be a good approach, example. And yes, it works well. Additionally css3 with table-layout: fixed and td with word-wrap: break-word had a good effect.

A new problem: double vertical scrollbars - a well known problem of jQuery Mobile - http://stackoverflow.com/questions/15737575/double-scroll-bars-when-using-the-panels-of-jquery-mobile-1-3-in-asp-net-mvc-4 mit


resetActivePageHeight:function(b){var c=a("."+a.mobile.activePageClass),e=c.height(),f=c.outerHeight(!0);b=d(c,"number"==typeof b?b:a.mobile.getScreenHeight()),c.css("min-height",""),c.height()<b&&c.css("min-height","100%")},

But this is not the appropriate approach, I adopted collapsibleset as wrapper for collapsible and everything works fine - only one scrollbar, if a table gets too long