[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: PNG File Screenshot 2018-08-24 18.31.33.png    
Issue links:
Relates
relates to STCOR-148 Allow modules to be of more than one ... Closed
relates to UXPROD-39 Local password management Closed
relates to STCOM-307 SPIKE: Local storage HOC/util Closed
relates to STRIPES-541 Create ui-myprofile module Closed
relates to FOLIO-3538 User-specific preferences Draft
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 ( UXPROD-39 Closed ).

We need to nail down several details of how this will work from the UX perspective, including but not limited to:

  • Names for the two kinds of persisted choices: at present it's just "Settings" at the tenant level and "Preferences" at the user level, but is that clear enough?
  • How best to deal with elements such as Locale which can be set at both the tenant and user levels (see FOLIO-3538 Draft )
  • How the two kinds of persisted choices will be accessed. (If they are both to appear as "apps", then the time may have come to think seriously about breaking Settings out into its own module).


 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 ]

Filip Jakobsen?

Comment by Mike Taylor [ 24/Aug/18 ]

Filip Jakobsen?

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).

However, from another perspective, it can be argued that the only part of a module's type that matters is whether or not it's an application. Modules of type app have a top-bar icon an a main-page application, but may also contribute any of the other functional facets that other module-types do: settings, preferences, a handler function. All other module types do not appear in the top-bar and do not provide a main-page application, but may contribute any or all of the other functional facets. So perhaps the only distinction we need between module types is between app and "other"?

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 ]
"hasSettings": true,

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:

module not having a type at all, but advertising what they can do.

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 STCOR-148 Closed but I'm very much against having another layer of choosing what is enabled and think that should be at module granularity.

Comment by Mike Taylor [ 31/Aug/18 ]

I don't understand that comment at all.

What I envisage is:

Users: has properties app, settings
Organization: has properties settings, preferences
My Profile: has properties preferences

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 ]

you can't take something that offers app, plugin and only turn on the app part.

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

Generated at Thu Feb 08 22:33:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.