simplify and beautify

The turnaround of data from the user to the local database and the remote database is robust and stable, the chat function is robust and stable and the ui is more stable and boring than exciting and attractive.

So the time has come to make the ui more exciting and more attractive.

General Points
The user-messages must be cleared after some time or when a page is navigated - there are some design-questions to clear and decide, before this can be done.

The splash screen
The splash-screen is shown for a maximum of 2 seconds and it has only technical data. Enhancements:

• colors unified
• shorter text - still work to be done, there should be a control-display of the systemdata, that can be displayed on purpose
• mouse indication system activity
• no redundant checking of system values and abilities

login page

The system information is displayed redundantly, better: 

• show only information relevant to the user (and not for the administrator)
• cookies must be allowed and are stored
• geo-location should be allowed, but that is no must
• active server
• active push server

register new user page

there are some enhancements

• the password has to have 6 to 20 digits, at least one small letter, one capital letter, one number
• http://www.w3resource.com/javascript/form/password-validation.php
• the password has to be entered twice
• copy and paste is not allowed for the second password entry
• the double input of the password is checked
• checkboxes are provided for the following acknowledgements
• the new user must accept the usage of cookies - otherwise the application cannot work correctly in session management (mandatory)
• the new user has to accept the storage of credentials for automatic login - otherwise the user has to reenter his credentials every time he wants to use the application (optional)
• the new user has to accept the testmode with restrictions to the content he is entering (mandatory)
• the imperative definition for this is a little bit tricky, but "easy if you know how"

$("#reguserForm")

.append($("<div/>", {

    class: "ui-field-contain"

})

.append($('<input />', {

    'type': 'checkbox',

    'id': 'checkCookies',

    'name': 'checkCookiesName'

}))

.append(

    $('<label />', {

    'for': 'checkCookies',

    text: "Cookies werden akzeptiert"

}))

.append($('<input />', {

    'type': 'checkbox',

    'id': 'checkAutoLogin',

    'name': 'checkAutoLoginName'

}))

.append(

    $('<label />', {

    'for': 'checkAutoLogin',

    text: "Automatischer Login"

}))

.append($('<input />', {

    'type': 'checkbox',

    'id': 'checkTestModus',

    'name': 'checkTestModusName'

}))

.append(

    $('<label />', {

    'for': 'checkTestModus',

    text: "Testmodus, vorsicht mit personenbezogenen Daten"

}))

);

 if ($("#checkTestModus").prop("checked")) { ...

• the username has to be checked
• when a new user tries to register, the eventually existing credentials of a former user have to be deleted, either in the cookies or in a local IndexedDB
• also the messages to the former user have to be deleted
• a newly registered user is directly passed to the start page, which is the calendar, he does not have to reenter his credentials
• a new username must be really new and not exist already in the database
• the cursor should be positioned to the first field and this field should be visible
• the page has a lot of data and input fields, so the button sometimes is hidden by the footer, specially when longer error messages are displayed in the footer for the user, that has been taken care of

// resize according to the size of the message

var actPage = $('body').pagecontainer("getActivePage");

var hh = $(actPage).find("[data-role=header]").outerHeight() || $(actPage).find("[data-role=header]").height();

var fh = $(actPage).find("[data-role=footer]").outerHeight() || $(actPage).find("[data-role=footer]").height();

$("#reguserpage").css("padding-bottom", fh);

var ch = $(actPage).outerHeight() - hh - fh;

// Cursor position to wrong field

$('#reguserpassword').focus();

• the code is for resizing according to the height of the footer and for cursor positioning - and it's pretty generic - but the global parameter for footer adaptation will be checked once more - and I have to admit that the problems came from parallel updates to the layout of different pages (the push message page was updated in the layout directly). Layout updates shall only be done on the active page.
• a conflict was there because messages from the registration where send to the push server, directly received and that lead to an interaction between the registration page and the push-/chat-page regarding positioning the scroll-position. Solution: rearranging the scrollposition in the push page is only done, when the push-page is the active page - that solved the problem
• when resizing, sometimes a second vertical scrollbar appears on the content, the first is on the page and that's ok. To avoid the second scrollbar I use on the content definition:
• css {"overflow": "hidden"}

calendar page

The calendar page can remain unchanged, there is a minor point regarding resizing. The datepicker widget which is used does not scale automatically, but a scaling effect can be used by changing the font-size, a smaller font-size makes the shape of the datepicker smaller accordingly.

This point is postponed.

The calendar page has a lot of additional functions that cannot be seen directly:

• getting all the dates with diary data from indexedDB
• getting all the dates with diary data from the server
• comparison of local and remote data
• check the local data regarding the username, if the user has changed, the old data is deleted for privacy reasons

Special points are:

• The color in the calendar fields for the dates is once more controlled, the colorization of the screen is removed, because it was used for testing reasons.
• blue - there are no local data but server data
• red - the data is local and not on the server, local data has to be saved in the remote server, this is done, when connectivity is there, it only applies to the app (Android, iOS, Windows 10)
• green - there are local data and data on the server for that day
• no color - no data available
• yellow - "today" and no data yet available
• the colors are assigned via css classes
• the globalization so far is prepared for Germany and Australia - but is is not configurable. The configuration will be done later together with the "first time configuration"

diary entry
the entry of diary data is rather sophisticated.
There are some details to enhance:

• display of existing entries - the layout has to be a little bit optimized, more compact - may come later
• entry of text is done with CKEditor or on iPad with normal textarea, the app checks it CKEditor is working and the fallback is the textarea
• income, expenses and worktime are collected in tables, the only point is that in 2017 income from work and travel (of course from the work part) is taxed in Australia with 19% - a design for that still has to be made
• rating of health, weather and mood is done with emoticons at the moment, an experiment with a slider was done, but is not implemented now

push messages
Some details have been enhanced:

• recognition of push-messages coming from the same username, these are not show to avoid cascading effects
• correct counting of incoming push-messages and updates to the footer 
• show push-messages in the message line of the footer, there the text has to be shortened and there will be a link to the push and chat messages from the footer, the following details where fixed

$("#pushmessage").val("");
$("#pushmessage").css({'height':'auto','overflow-y':'hidden'}).height($("#pushmessage").scrollHeight);

Surprisingly it was not easy to reset the message textarea height to one line. Another critical point is positioning the listview to the last element in the push and chat client. That has to be done when a new message is entered or a new message is received while the page is the active page.
The solution had to make a difference between app-mode and browser-mode.

In browser-mode: // $("body").scrollTop(totop);
$(window).scrollTop(totop);

is very easy, in app-mode the logic uses parentScroll and an iteration. But this does not work in appMode and there are Problems on the iPad - some work to do

Responsive Design
on the level of elementary input and of tables the responsive design has been implemented, now it's time to regard the general layout of applications - separate chapter.