Enhanced functions go beyond the core diary functions.
November 21, 2016 - update on the progress
On the one hand side the aspect of income, expenses and working hours can be extended far more to projekt costing, and many other aspects until taxation on work and travel in Australia.
But the aspects of community oriented functions are much more interesting and challenging:
- themes can be given to diary entries, like politics, economy etc.
- you not only write what you were doing but also write what you think and feel
- and you can comment and vote on texts
- agree
- disagree
- irrelevant
- don't understand
- search functions can support finding themes
- realtime messaging about comments and votes
On the other hand there are some functions still under construction and these should be finished first. So what bothers me:
- make entry panels responsive (done)
- entry of data is necessary - independent of the device, the user has the choice so there may be no restrictions on the user. Tabular entry is a must and for the smartphone there must be an automatic conversion in a responsive way to compensate jQuery Mobile deficits
- table with classic rows works excellent
- jQuery Mobile offers data-role="table" class="ui-responsive" for automatic conversion, it looks not the best, but it's acceptable, just the space between subtables is too big, it comes from a column that is reserved for buttons in the input row, optimization is postponed
- new aspect: so far the elements of dialogues were considered regarding responsiveness, now the general layout of of dialog has to be optimized (open)
- security still has white spots (done, no detail-link for coreader)
- protection of diary entries against unauthorized changes can be done in two ways:
- complicated way: if a user sees input fields, he gets bad feelings if an input is ignored, it's better to have native display than to have protection on input fields, display mode is necessary for co-reading and for "old diary entries". Data in the ui must get an edit mode and a display mode, not very much work, but very important
- simple way: no link to detailed display and edit-panel for coreaders - the simple way has been programmed (done)
- only new data may go to the server, not redundant old data
- a public reader option will be added in a future release - if that is done, the a publish-date will be introduced, that makes sure, that a user can write the diary during vacation, but the vacation is only visible in the public when he is back at home
- the data model may need some enhancements for that
- opportunity to enter diary entries for days in the past (done)
- the additional entry to dates in the past is provided as special function with a flyin menue in the entry dialog, the datepicker is provided to simplify date entry.
- the datepicker shows the days which already have a diary entry with a special background-color, see http://www.jquerybyexample.net/2012/05/highlight-specific-dates-in-jquery-ui.html and http://www.dotnetcurry.com/jquery/1209/jqueryui-datepicker-tips-tricks, but the right trick came from: http://stackoverflow.com/questions/9023818/correct-way-to-change-specific-dates-cell-background-color-on-datepicker
- new startup for the app - calendar (done)
- the first page still remains the login page, but the second page changes (the app may start with the calendar skipping the login)
- a calendar as startup can show the actual day and month and the days which already have data are marked by color
- the calendar can be used to navigate to the past and to the future, so reminders for coming days can also be entered
- a flyin-menue can give additional choices, so the classical menue is not longer the start
- problems on iOS, first step: enhanced logging
- copy to the report field (done)
- so far there was a preventDefault on the past action to the text input
- that has been refined, so past is possible
- the formating gets lost, perhaps that will be refined in a later release
- Remember me on login (done)
- a cookie stores the credentials
- enrypted data in the cookie
- cookie is deleted if remember me checkbox is set off
- Rich text in the entry field (done)
- choice of standard tool for rich text entry
- additional comment-function for co-reader
- ckeditor requires ressources, may be it's better not to allow it on smartphones and only on tablets, laptops and desktop
- realtime messages to the users (done)
- the administrator can enter messages to users, e.g. regarding updates or new functions in the app
- a counter of these messages is shown in the footer
- a special chat dialogue is provided for push messages and chat
- a channel system gives structure to the messages, only certain messages go into the message area in realtime
- the messages are shown on the login page and in the message area
- the user acknowledges that he has read the messages (later, may be)
- initial performance on startup of the browser-solution
- the start of the app gives the first impression, slow start gives a bad impression
- aggregate js files to one file
- compression of the file
- using cache of the browser and controlling the cache from the browser app
- automatic update to the cache with new versions of js files
- persistent data in the browser if the network connection is down
- thats difficult, because the browser has no cross platform storage
- but a fallback for emergency cases is the requirement, not a local database
- cookies and local files are real candidates for the solution
- translation is really an issue
- I really like the idea of international engagement in discussions on one subject
- I made good experience with machine translation
- I learned that text has to be written in a machine translation friendly manner
- realtime feedback by votes and not only by chats (text)
- that's also a personal issue
- votes are an abstract feedback to a subject - easy to aggregate and easy to do
- votes are a good opportunity to express emotions in a constructive manner without offense
- votes are transformed to push-messages in a votemessage channel, this will make it easy to implement
- the vote is transferred as message to the server
- the server calculates the counters
- the counters will be send to the users, not the individual votes
- put all functions into an app (done)
- that was an easy part, the js files are shared
It is not easy to decide priorities, but I can only program one step after the other. Do I added the priority aspects to the above points.
No comments:
Post a Comment