March 20, 2012 Drupalcon BOF "Context" User Stories

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Context is a (over) loaded word.

During the BoF we came up with a number of user stories. The purpose of these stories was not to come up with how to do these things. The purpose was to come up with stories related to the many different ways the word "context" is used throughout Drupal so that the language can be disambiguated.

What meaning of "context" is expressed in each story?

Try to use a synonym or other word that captures the meaning of "context" in each story. Some words or phrases that came up were:
"Arguments or Parameters that are passed"
"Related information or Related content or Relationships"
"Situational"
"History or Past user action"

The hope is that we can have standard and meaningful language in discussions about UX design for Layouts in Core.

  1. As a site builder I would like to be able to get a list of all articles published by the current user.
  2. As a site builder I want to display a badge to the user on the fifth page view.
  3. As a site builder I want to embed a view of related nodes into a node page.
  4. As a site builder setting up a node page I would like to be able to access node author data.
  5. As a site builder I want to be able to include a menu based upon the section of the site I’m in.
  6. As a content editor I want to control where fields of this node appear within a layout.
  7. As a new user I expect contextually aware help.
  8. As a site builder I want a certain block to show up for users of a specific role when visiting a particular node.
  9. As a site builder, I want to be able to load up nodes referencing this node or reference by this node.
  10. As a site builder I want to place a block by a path.
  11. As a site builder I want to allow customization of the visibility of a specific block, by user, for themselves.
  12. As a user I want to build a customizable dashboard for myself.
  13. As a site builder I want a certain block to be visible based upon navigation history.
  14. As a site builder I would like to ensure that users must agree to terms and conditions before viewing specific content.
  15. As a visitor, I want to be able to see what forum I’m in when viewing a specific thread.
  16. As a site builder I want to be able to vary the theme based upon the current OG.
  17. As a site builder setting up a node page I want to be able to send any or all taxonomy term as an argument to view.
  18. As a content editor, when I’m looking at a node I want to be able to create a new node with a reference to the node I’m currently looking at.
  19. As a content editor, when viewing a node, I want to be able to be able to add another node within the same OG.
  20. As a logged in user, I want to see a block with my pic and various other stuff specific to me.
  21. As a site builder embedding a view that requires a node context I want to be able to manually enter a node id instead of a dynamic node.
  22. As a site builder I want to display the top node in an arbitrary node queue.
  23. As a site builder I want to be able to define menu relationships on node creation through some form inheritance.
  24. As a site builder I want to be able to manually specify breadcrumbs and active menu item for any page.
  25. As a site administrator I would like to specify the rules for determining bread crumbs
  26. As a visitor I would like to be able to page to the next/previous node of a specific bundle.
  27. As a site builder I would like to specify how I navigate from one node of a specific type to the next.
  28. As a site builder setting up a node page, setting up a view that requires a string as an argument.
  29. As a site builder I want to be able to display extended term information for terms in a specific vocabulary which this node is referencing.
  30. As a site builder I want hide author information in the teaser.
  31. As a site user, I want the site builder to be able to tell me what to do next.
  32. As a site administrator I would like to control which fields on a given content type can be edited by which roles.

Comments

themer

dozymoe's picture

Can we have this one in there (or is it out of scope?):

As a themer, I don't want to be a site builder. I just want to care about layouts, colors, font styles, etc. I don't care where that data came from, only if it's in the format agreeable to me. If I am a poor programmer I'll ask for simple text, and if I know programming I'll asked for a more complex data structure.

We have just created

Bojhan's picture

We have just created http://drupal.org/node/1510532, a interesting usecase there would be to allow people to configure how the content creation screen looks like.

(http://drupal.org/node/15105

yched's picture

(http://drupal.org/node/1510532 links here for the "How to make this all configurable?" item, so I guess this comment belongs here rather than in the issue ?)

So one of the technical challenges about the design proposed in http://drupal.org/node/1510532 is the "taxonomy" section as an accordion in the sidebar.

Since D7, taxo fields are regular Field API fields, whose placement in the form is freely controllable from the "Manage fields" page., whereas in D6 taxo fields in a node were hardcoded in a dedicated "Taxonomy" fieldset. I don't think we want to add a special case on taxo fields to hard-place them back in a forced location.

So the screenshot tends to imply that the "Manage fields" page (or some new spiffy formbuilder-like incarnation) exposes the sidebar and the concept of "accordion block" as part of the UI interaction. In D7 doing such a thing currently requires DS + Field groups contrib modules (D7 core UI, for instance, doesn't interact with the vertical tabs section).

The DS side would likely be managed in D8 by the "layouts" UI. But the accordion sounds like "(some of) Field groups in core"

Forgot to add : on a gut

yched's picture

Forgot to add : on a gut feeling, I like the proposal, but I don't really intend to weigh on the relevancy of the design choices, I trust you guys for this :-). Only chiming in on technical implications.

@yched Thanks for chiming in.

Bojhan's picture

@yched Thanks for chiming in. We definitively don't want to hard-code them into one location. The design proposal primarily focuses on showing what "could be there", one of those could be taxonomy.

I think your technical proposal is what we where thinking as well, it will be a bit of a challenge to actually get VT's or accordion tabs to work well within the layout model (e.g. can you just drag and drop items into the VT/accordion rows? - can we standardize this interaction? how do you find VT settings?) but that's a challenge we can overcome.

batsonjay's picture

Editor Ellie, the advanced content creator role. The list above makes the classic Drupal practice of assuming there are site builders that are expert Drupalists, and content creators that merely add text to a node body.

I'm assuming the above user story list is primarily intended to help define terms & language; but since I know that enabling this user / function is part of your goals, it would be great to have some of those stories in this list in order to influence the term / language definitions. :-)

Add client-side JS content cases

batsonjay's picture

All those stories more or less assume Drupal is server-side page-build.

With an increase in client-side page build (i.e. JS that pulls stuff from the server & assembles as desired), there ought to be some stories here that explicitly call out that type of scenario. You sort of have this in the Dashboard story, but that's too limiting.

A couple of example stories:

  • As a site builder I want (some or all of) a target page to be displayed using JS callbacks to the (Drupal) web server, obtaining a specific (Drupal) View based on the value of cookies present in the visitor's browser.
  • As a site builder I want to provide progressive loading & display of a very long (Drupal) view based on some browser (user) action, such as scrolling to the bottom of a page, or if a user clicks a "show more" (entries) button at the bottom of a page (showing more in either case simply by adding more rows to a view without a new page, or a page reload).
  • As an advanced content creator, I want to enable an A/B-MV test that displays all, or a portion of a page differently based on either random selection or based on variables present in cookies in the visitor's browser. (Note: For this story, the influential element is a presumption that this would be implemented by client-side JS that makes a content-call back to Drupal. This story can be implemented server-side, but by forcing the implementation to be done client-side, it may have influence on the framing / language discussion.)