• 1 year ago - link
    by @ghost

    [bins-12]

    back: bins-0

    Proposal

    A UX pattern I haven't seen very much is the modal interface. not modal as in a popup, but as in several modes of user interaction, akin to Vim. In help mode, clicking an element simply explains the element, rather than triggering the action.

    Let's evaluate such an interface on the standards we designated above:

    • discoverable
    • no need to leave the app
    • workflow directed by user
    • on demand
    • minimally intrusive, low ScRE use
    • no sudden popups that content or interrupt the user
    • clipboard friendly, text selectable friendly
    • use case driven
    • "borrows" ScRE instead of stealing it bins-6
    • extensible
    • contextual

    It's very similar to what a hands on learning experience is like in the real world. It's tactile to be able to touch things, ask what they are, and learn about them.

    Now, drawbacks:

    • Uncommon design pattern--modal interfaces are not familiar or intuitive to many
    • Not comprehensive - the user has to already be in the correct app context to explore and discover how to achieve their usecase
    • Initial disovery and intuition--would likely require animated introduction to the concept of dragging a "button"

    I feel like this is a good balance for such an integral part of your app experience. UX help elements should be neither seen nor heard until called upon by the user.

    To address the shortcomings, I would propose a chat bot that operates like a command terminal. It should accept use cases and provide users with direct, deep links to accomplish those use cases. From there, the user can use the modal help tool to discover the page. The bot can recommend articles for in-depth help or explanation. Lastly, the bot can escalate to support with documentation for the issue already collected from the user.

    These two in combination address nearly all the drawbacks and standards we discussed.

    1. both have extremely high value prop to ScReF
    2. both are on demand
    3. both are contextual and do not require leaving the app
    4. both are ScRe loaners and can be exited or closed at any time
    5. both are clip and select friendly.
    6. neither interrupts the user or obscures content without explicituser permission.
    7. both are easily augmented with additional documentation

    back: bins-0

[bins-12]

back: bins-0

Proposal

A UX pattern I haven't seen very much is the modal interface. not modal as in a popup, but as in several modes of user interaction, akin to Vim. In help mode, clicking an element simply explains the element, rather than triggering the action.

Let's evaluate such an interface on the standards we designated above:

  • discoverable
  • no need to leave the app
  • workflow directed by user
  • on demand
  • minimally intrusive, low ScRE use
  • no sudden popups that content or interrupt the user
  • clipboard friendly, text selectable friendly
  • use case driven
  • "borrows" ScRE instead of stealing it bins-6
  • extensible
  • contextual

It's very similar to what a hands on learning experience is like in the real world. It's tactile to be able to touch things, ask what they are, and learn about them.

Now, drawbacks:

  • Uncommon design pattern--modal interfaces are not familiar or intuitive to many
  • Not comprehensive - the user has to already be in the correct app context to explore and discover how to achieve their usecase
  • Initial disovery and intuition--would likely require animated introduction to the concept of dragging a "button"

I feel like this is a good balance for such an integral part of your app experience. UX help elements should be neither seen nor heard until called upon by the user.

To address the shortcomings, I would propose a chat bot that operates like a command terminal. It should accept use cases and provide users with direct, deep links to accomplish those use cases. From there, the user can use the modal help tool to discover the page. The bot can recommend articles for in-depth help or explanation. Lastly, the bot can escalate to support with documentation for the issue already collected from the user.

These two in combination address nearly all the drawbacks and standards we discussed.

  1. both have extremely high value prop to ScReF
  2. both are on demand
  3. both are contextual and do not require leaving the app
  4. both are ScRe loaners and can be exited or closed at any time
  5. both are clip and select friendly.
  6. neither interrupts the user or obscures content without explicituser permission.
  7. both are easily augmented with additional documentation

back: bins-0