Open grumpyinca opened 1 year ago
grumpyinca
commented
1 year ago If a cookie approach is implemented, there should be a mechanism to clear the cookie. Perhaps this could be an execute script. Perhaps a more granular approach involving Preferences is the right answer.
grumpyinca
commented
1 year ago Today's conversation touched on various issues and concerns regarding this proposal. A few of these include:
A truly comprehensive and robust implementation may end up looking like an internationalization mechanism where all text strings are extracted into a separate "resource" file and appropriately indexed.
If such a generalized external approach were utilized, where should the threshold values be stored ? In the cookie ?
grumpyinca
commented
1 year ago Another possible application of the feature(s) described above is in providing control for a prompt to respond to a survey question. Specifically, a user that has performed a specified count of Searches could be prompted to rate their experience on some scale.
Potentially, this prompt may be triggered only by the BeforeUnload event. The results could go into the usageLog.
Many different kinds of survey questions could be established over the course of succeeding ODOP releases.
Objective / Mission statement
It is desirable to adapt the ODOP user experience based on a user's previous experience with the app. Specifically, it is desirable to use counts of what a given user has seen (tooltips, hints, AutoFix highlights, Welcome script) to selectively disable display of those elements in the future. Thus, the effect is an automatically configured transition from the previously described (See: #756) "novice mode" to "expert mode". The net effect should be to allow future development of more "just in time" assistance for novice users while maintaining a cleaner user interface for experienced users.
Background / Context
Currently, all users, first timers and highly experienced repeat users alike, get the same treatment (user experience) when launching and using the app.
SpringDesignSoftware.org currently provides three paths to form the query parameter string and launch the app:
Options #2 & #3 always execute the appropriate Welcome script (welcomeAdv.js or welcomeCalc.js).
A previous proposal to implement a "been here before" cookie and associated behavior change on the SpringDesignSoftware.org side was investigated but abandoned based on development difficulty. Thus, this discussion is in the context of implementing something on the odop.herokuapp.com side.
Proposed first case
As a first step, it is desirable to eliminate repeat displays of the Welcome Script for returning users. Perhaps the mechanism can be so flexible as to suppress display of the script only when all pages have been viewed at least once and the first page viewed at least n more times.
Ideally, the selected approach to suppress the Welcome script can be extended to change other aspects of the user experience based on the user's previous activity and experience level.
Implementation possibilities
There are at least two mechanisms for obtaining and/or retaining information about an unregistered user's previous activity with the app:
Each mechanism has its own limitations. The relatively common usage of VPNs likely makes the cookie approach more reliable and extensible. Each usage of the app should leave or update a cookie in the user's browser. This cookie can retain the cookie's version, a count of the number of times the app has been launched, the number of searches executed, etc.