[UIP-1] Figure out UX for settings vs. preferences Created: 13/Jul/18 Updated: 31/Aug/18 Resolved: 30/Aug/18 |
|
| Status: | Closed |
| Project: | ui-preferences |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Mike Taylor | Assignee: | Mike Taylor |
| Resolution: | Done | Votes: | 0 |
| Labels: | sprint42, sprint43, sprint44, sprint45 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||
| Description |
|
Stripes currently supports a notion of Settings, such as Locale and Loan Policies, which are at the level of the tenant. We now also need to support user-level preferences, most immediately to support change passwords (
We need to nail down several details of how this will work from the UX perspective, including but not limited to:
|
| Comments |
| Comment by Mike Taylor [ 13/Jul/18 ] |
|
Part of the output of this discussion will be some technical requirements – e.g. we may find we need to move to the long-mooted approach where each Stripes modules can be of multiple types (app, settings, prefs, plugin, etc.) But let's try to postpone those technical discussion for a subsequent issue, and concentrate for now on what we want to do rather than how we will do it. |
| Comment by Mike Taylor [ 13/Jul/18 ] |
|
Much as I hate conference calls, I suspect the best way forward with this one would be a call in which Jakub shows and explains what he presently has for Preferences, and tells us what changes he'd like to make. Then we can discuss from there. When would be a good time? Jason usually come online around 3pm my time, which is 4pm for Filip and 10am for east-coast USA – is it 9am for you, John? If so, then my preference would be to just get it done, and meet at that time today. |
| Comment by Mike Taylor [ 25/Jul/18 ] |
|
Filip Jakobsen Are you there? |
| Comment by Mike Taylor [ 01/Aug/18 ] |
| Comment by Mike Taylor [ 24/Aug/18 ] |
| Comment by Filip Jakobsen [ 24/Aug/18 ] |
|
Hi Mike Taylor, Sorry for not getting back on this. I get a lot of emails from JIRA on topics that are not relevant for me, and the email titles on the emails on this issue made it look like I was not being tagged. I'll reach out to you on Slack so we can proceed more quickly with this. Thanks, |
| Comment by Mike Taylor [ 24/Aug/18 ] |
|
Thank you! |
| Comment by Mike Taylor [ 28/Aug/18 ] |
|
Very useful discussion with Filip Jakobsen this afternoon. I will write it up tomorrow. |
| Comment by Mike Taylor [ 30/Aug/18 ] |
|
Done: https://github.com/folio-org/stripes-core/blob/master/doc/settings-and-preferences.md |
| Comment by Mike Taylor [ 30/Aug/18 ] |
|
Filip Jakobsen will you please review that document and check that it doesn't contradict anything in our conversation from Tuesday? Jason Skomorowski Zak Burke Michal Kuklis Your thoughts, please, on the technical aspects. |
| Comment by Matthew Jones [ 30/Aug/18 ] |
|
Great write-up Mike Taylor. I like the idea of exporting the app, settings, and preferences (and invoking them in a backwards compatible manner).
Possibly. I am finding various conditions in the CLI for "type === app" fail in cases where they should work simply because this condition is too narrow when run on a settings module. Simplifying to "app/other" could fix that (as would minor updates to the test condition itself). However, I think extra detail can useful. We might also consider using properties that describe the available behavior, rather than inferring what is available from "type". "stripes": { "hasMainPage": true, "hasSettings": true, "hasPreferences": false }, We also have a type of plugin, and I suppose a plugin might have its own settings or preferences, but no main navigation. |
| Comment by Matthew Jones [ 30/Aug/18 ] |
Oh right... It occurs to me now we already do this with settings. |
| Comment by Mike Taylor [ 31/Aug/18 ] |
|
Interesting. Perhaps the notion of modules "having multiple types", which has always felt awkward to me, was always just groping towards the idea of module not having a type at all, but advertising what they can do. A move towards duck-typing, I guess. |
| Comment by Jason Skomorowski [ 31/Aug/18 ] |
|
Yah, I've come to see the types as interfaces essentially and think that notion would do well here. "This module provides (wants to integrate into the system as): app, settings, preferences" |
| Comment by Mike Taylor [ 31/Aug/18 ] |
|
So, Jason Skomorowski, would you support the notion of actually dumping the concept of type completely? And replacing it with a set of roles? |
| Comment by Michal Kuklis [ 31/Aug/18 ] |
|
Mike Taylor I like this idea:
a lot! |
| Comment by Jason Skomorowski [ 31/Aug/18 ] |
|
Yes, provided the module is still enabled/disabled atomically eg. if you want to be able to use a module as a plugin AND/OR an app ...that's two modules. I'm very much for the multiple types / roles described in
|
| Comment by Mike Taylor [ 31/Aug/18 ] |
|
I don't understand that comment at all. What I envisage is: Users: has properties app, settings That that you mean, too? If so, then ... is there anything we disagree about? |
| Comment by Jason Skomorowski [ 31/Aug/18 ] |
|
Yup, that's what I mean too. Where I think there might be contention is my constraint that either a module is either enabled or it's not eg. you can't take something that offers app, plugin and only turn on the app part. |
| Comment by Mike Taylor [ 31/Aug/18 ] |
Are you lamenting that this is the case, or asserting that it should be the case? (I guess I don't feel too strongly either way, so I'm happy to just let you have this one |
| Comment by Jason Skomorowski [ 31/Aug/18 ] |
|
Asserting that it should be that way because it keeps things simpler. |
| Comment by Mike Taylor [ 31/Aug/18 ] |
|
ok |