Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

 User Problematics List

This page lists the "user problematics" or "pain points" identified through the walkthrough exercises and from other sources.  Where possible, each item in the list should link to a description of the problem it represents, any principles that apply, and the process through which it was identified -- e.g. the walkthrough exercise that revealed it.  If there is a relevant Component Solution, that too should be referenced.

Everyone is invited to contribute to the list.  While desirable, descriptions are not required. 

My distillation of initial pain points - note that this is "to some extent" from a developer perspective, and is not from a walkthrough, but just "off the top of my head":

  • Preferences: The preferences system is currently "hard-baked", and has a hard dependency on each application which exports preferences. As a result there are really only about 4 apps which have bothered to do this since each further one creates a dependency risk and involves committing to core code. From the UI perspective, other than the simple inhibition on expressing any UI for preferences at all, we have the risk that preferences cannot be reaggregated. It should be possible for them to appear both contextually at the point of application, as well as in some central aggregated ("synoptic", that dirty word) overview of a single users entire preferences. And, of course, from the developer perspective should be hosted in the tool/component itself, rather than in any kind of central "Preferences Service".
  • Permissions: The permissions system similarly has a single "one-size-fits-all" view full of a huge heap of tickboxes. These cannot be placed "close to the tools", unless the tool defines within itself a
    completely custom view, which once done, conversely cannot be dispatched back to a central location! Steve Githens has been doing work on a "permissions helper" but the scope of this should ultimately be expanded.
  • "Resources"/Portal: "Resources" has to be the central target. The best we have been able to do so far in "reaggregating" is the system of "helpers", whereby one tool briefly takes completely control of the render pane, until such time it decides it has finished at which point it dispatches back. These things are generally so arcane and nonstandard that again few people have managed to create any unless impelled by really strong "pain points" of design. Each one in general uses its own URL mapping and back-dispatching strategy... I am expecting that one of the core deliverables we will construct in Fluid is an exhaustive catalogue of the different UX patterns that could result from "includable" units of resource choosing, resource presenting, resource manipulating applications. An ultimate goal is to "fold" the portal navigation structure to more closely resemble the resources structure. What is currently the Resources "Tool" should be capable as acting as both consumer and exporter of UI estate. "Tools" should appear within Resources, and "Resources pickers/viewers" within tools. Right now we can do neither.


  • No labels