Last updated by User Advocate on Wed, 2012-04-11 20:35
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.
- As a site builder I would like to be able to get a list of all articles published by the current user.
- As a site builder I want to display a badge to the user on the fifth page view.
- As a site builder I want to embed a view of related nodes into a node page.
- As a site builder setting up a node page I would like to be able to access node author data.
- As a site builder I want to be able to include a menu based upon the section of the site I’m in.
- As a content editor I want to control where fields of this node appear within a layout.
- As a new user I expect contextually aware help.
- As a site builder I want a certain block to show up for users of a specific role when visiting a particular node.
- As a site builder, I want to be able to load up nodes referencing this node or reference by this node.
- As a site builder I want to place a block by a path.
- As a site builder I want to allow customization of the visibility of a specific block, by user, for themselves.
- As a user I want to build a customizable dashboard for myself.
- As a site builder I want a certain block to be visible based upon navigation history.
- As a site builder I would like to ensure that users must agree to terms and conditions before viewing specific content.
- As a visitor, I want to be able to see what forum I’m in when viewing a specific thread.
- As a site builder I want to be able to vary the theme based upon the current OG.
- 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.
- 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.
- As a content editor, when viewing a node, I want to be able to be able to add another node within the same OG.
- As a logged in user, I want to see a block with my pic and various other stuff specific to me.
- 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.
- As a site builder I want to display the top node in an arbitrary node queue.
- As a site builder I want to be able to define menu relationships on node creation through some form inheritance.
- As a site builder I want to be able to manually specify breadcrumbs and active menu item for any page.
- As a site administrator I would like to specify the rules for determining bread crumbs
- As a visitor I would like to be able to page to the next/previous node of a specific bundle.
- As a site builder I would like to specify how I navigate from one node of a specific type to the next.
- As a site builder setting up a node page, setting up a view that requires a string as an argument.
- 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.
- As a site builder I want hide author information in the teaser.
- As a site user, I want the site builder to be able to tell me what to do next.
- As a site administrator I would like to control which fields on a given content type can be edited by which roles.
Comments
themer
Can we have this one in there (or is it out of scope?):
We have just created
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
(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
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.
@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.
There's a category of user - and story - missing here...
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
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: