axa-ch-webhub-cloud / inno-day-time-boii Goto Github PK

after merging #19 trigger refresh after every change of any times

It would be nice if the AXA time tracker could tell me that I have worked enough for today!

Implement something inobtrusive, especially for mobile. The device could e.g. vibrate to indicate end-of-workday or show a native notification or both.

E.g. use https://developer.mozilla.org/de/docs/Web/API/Navigator/vibrate and https://developer.mozilla.org/de/docs/Web/API/notification.

When navigating to a new day, users doing batch data entry expect focus to be on the first unfilled input field.

Implement this.

Debatable: Tab order currently includes delete action buttons. Arguably they are rare. Maybe they should be skipped in tabbing?

The app has rudimentary, untested code for Excel already.

But nothing is wired up or works yet.

Define the simplest possible Excel structure that

• contains all the time-keeping data that the indexedDB has
• allows to copy-paste from the export Excel sheet to an
  official Excel time sheet in a reasonable number of manual steps

Implement Excel download of entire time-keeping DB from indexedDB to local file with sensible file name.

Include human-readable date-of-export in file name.

Discuss whether or not to include personal identifying information (PII) such as the employee number or not.

The app already possesses code to calculate the cumulative work hours for the current year.
Management likes to ask employees at unforeseen moments whether they have overtime.

Taking into account the settings-defined and persisted daily hours requirement (default: 8.4h), therefore work out over/undertime and display that in the UI somehow.

Showing such info might need to be configurable in the settings if it is found to be too distracting for some users.

Currently, the date is updated on navigation only. As part of such updating, natural-language characterizations such as 'Today', 'Yesterday' are added when appropriate. If, however, one leaves an instance of the AXA Time Tracker open overnight, it will not update either the date or the natural-language characterization of it.

Do some UX research on what users expect and implement the sensible thing to do based on your research. You may need https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API to update only when needed.

Also, nothing in the UI indicates that the hours-worked and earliest-time-to-live times are live and updated every minute.
One way to improve the UX is to have a blinking colon separator (with 1Hz frequency).

Implement this efficiently, using only CSS.

For instance, use chrome.storage which could be synced over the network (not the best solution since browser specific) or try anything with WebRTC.

An earlier iteration on the UI displayed the duration of pauses between subsequent time intervals.

This is useful information for habit formation that users will want ('oh, I keep having too long lunch breaks...').

Add that back in a tasteful way, possibly configurable in the settings.

Click "KOMMEN". The time on the top right is wrong.
see sshot:

The current time-manager statistics (work hours left, earliest time to leave) are mocked and static.

Recalculate them dynamically from time-keeping data of the current day.

Ensure this works under day-to-day navigation.

On import-export.js:90, target may be undefined. So, although all the importing behind the scenes went fine, an alert with an obscure error pops up.

Investigate and fix this.

Currently it is difficult to see whether you have undertime or overtime in the currently tracked work day. One has to perform mental arithmetic to calculate which one is the case.

One nice way to visualise this is using small pie charts, 1 per hour. A green background symbolizes overtime, a red background undertime. E.g. 1 h 45 minutes overtime is 1 full-circle filled green 2D 'pie' followed by 1 three-quarters filled green 2D 'pie'.

Implement something like this.

Technical hints: use a programmatically constructed simple SVG with a circle path and two straight-line paths, plus CSS-class-controlled fill property.

On small mobiles some of the CTAs might be too small, hence prone to unexpected bad UX due to fat fingers and small hit targets.

Review the entire UI, and adjust sizes where necessary.

Double-check that the app adapts to mobile viewports. Document that it supports common viewport sizes.
Minimally support portrait mode of typical smartphones, from 320px and above.
If issues are found, fix them. E.g. on 320px time entry fields only show the hour part.
Attach screenshots for documentation purposes in comments.

The app shows a peculiar mix of colours against a fixed official logo.
Explore ways to beautify the design w.r.t. colour.

One idea is to reuse logo colors in other UI elements, esp. button background colours. Online tools can help calculate lighter versions of those colours.

The end goal is better colour harmony in the app design.

As it stands, the app is standalone and backend-free. Hence, data could be lost that was painstakingly entered over month! As a cheap form of backup, one could email oneself the time-keeping data periodically.

Browsers support mailto links. This can be used in programmatic fashion.

Try to allow the Excel export from issue #3 to be mailed out from the device. This would entail extending the settings to support storing a default email address.

Work out a sensible subject line, and experiment with more or less convenient email-body formats.

Document your design decisions in comments to this ticket.

One important usage scenario is batch entry of times from another medium, e.g. paper notices.

There, speed of data entry matters. Hence, we need keyboard shortcuts for important subtasks.

These include - but are not limited to - the following:

• Enter for a new time pair
• left arrow/right arrow for going back/forward by 1 day
• Shift+left arrow/right arrow for going back/forward to last/next filled day

If one clicks on the icon image of a Start/Stop (German: Kommen/Gehen) button, one may not observe any action.

Expected: a time entry is always filled, if necessary by creating a time-pair row first.

Fix this.

The worked-hours amount next to the hourglass icon can be wrong upon navigation to filled days in the past (depending on the time-of-day when that navigation is performed).

The culprit seems to be time-manager.js:79 where a historic startTime is compared to the current time (of today).

Fix the calculation so that it is correct under all circumstances.

Currently, when using between manual time entry and Come/Leave buttons, anomalies occur.

For example, a filled-in time-interval start does not result in the Leave (Gehen) button being activated:

Also, after a Come/Leave-triggered time pair the Come (Kommen) button looks active, but does not respond to clicks (expected: by opening another time-pair line):

Third, when adding another time-pair line using the plus button, an empty line is correctly added, but the focus is on the top-of-page time-interval start field. In the same situation, the Come button correctly looks active, but actually clicking it can give varying results, like another time-pair line being appended (expected: reuse the last, empty line) or filling in the time-interval end field and remaining active (expected: Come button only ever fills the start field of a line, Leave button active):

Define rigid interaction rules that match user expectations and at least rule out the above anomalies.

Then implement them to fix this issue.

By executing Clear Browsing Data functionality on a browser, an app user could accidentally delete months of time-keeping data.

Try to make it harder to lose data this way by using StorageManager methods, esp. persist.

Nice to have would be a display of the storage used in some nice format.

The Come/Go action buttons do not fill in or create time entries.

Fix that.

The (currently inactive) download/export icon in the top-right corner is unintuitive. Find a better SVG icon (possibly from Material design icons) that has the right affordance.

The app has no favicon. Add a simple one (if nothing else, an already existing AXA favicon might do).

Currently this app is broken, since it loads an old lit-element version from unpkg which now fails:

Upgrade this app to the latest lit version (3.0.0) and use jsdelivr instead!

Currently each time interval implicitly is of type work (the default).

But, there are other types of intervals, e.g. ' doctor's visit', 'sick leave', etc.

Currently, these cannot be distinguished from the default interval type.

Research sensible UX/UI for changing a time-interval's type. Add images of paper sketches of some design alternatives to this ticket. You may find QOC useful to choose between these alternatives.

Then implement your chosen UI, and adapt the underlying (persisted) data model accordingly.

The app currently can't start without an internet connection.

Make it offline-capable by using a service worker. E.g. start from this example.

One potential difficulty is that we are exploring a build-free environment for developing this app.
But service-worker-cached assets often use content hashes in their filenames so any change leads to easy service worker reloading. Content hashing is a build step... Find ways to solve or sidestep this issue, possibly later.

Nice to have would be a simple URL-based kill switch to force the service worker to reload/re-cache from the network.

Also nice to have would be an offline icon to show the user what state we are in.

Currently the time tracker uses device-local storage only (indexedDB). This is desirable from a privacy-first point of view, but creates problems from a backup point of view.

By way of example, it means that a year's worth of data could be lost e.g. due to accidental 'clear browser data' operations.

Implement a minimal but working way to export a JSON serialization of the time-tracker's indexedDB content (e.g. to a file in the Downloads area, or to email).

Also implement a minimal but working way to import a previously exported JSON, so that the time-tracker's indexedDB content is entirely overwritten with the JSON content.