launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

Christian Robottom Reis wrote:
> On Thu, Aug 06, 2009 at 01:13:02PM -0400, Curtis Hovey wrote:
>>> What is the deciding factor for whether an action can be placed in the
>>> main content? Is the Related Pages menu supposed to be in the main
>>> content or the sidebar? Can you provide an example of the contents of
>>> the two menus for an overview page, an edit page, and a bugs page for
>>> a single object?
>> The action menu is for actions that change the context object. Many
>> objects do have content to place a link near. Common examples in the 2.0
>> UI is Change details and Administer. Recent examples are Change password
>> and Change visibility (pubic/private). Since these links modify the
>> context object, they will probably only appear on the context's index
>> page. Something is wrong if:
>>
>>       * The menu shows up on many pages
>>       * The menu has more than 3 links (experience may change this
>>         number)
>>       * The link does not modify the context

OK, so I'm still a bit confused regarding this point for items in the
action menu. As I understand Curtis' definition, the link needs to be
for an action that *modifies* the context (I'm assuming we're talking
about the context *object/s* from the user's pov here, rather than the
more general concept of the context of the page - perhaps that's a wrong
assumption?).

> 
> Mostly agreeing but elaborating on Curtis' answer since he didn't
> actually provide any examples <wink> I think the decision of where to
> put a link is actually pretty easy if the idea behind the actions menu
> is "links in the actions menu are all the links that manipulate
> something that isn't intuitively identifiable on the page." The page

Yes, that definition makes sense, I'm just not sure if you're implying
something different from "The link must modify the context". So, to
point out the ambiguity in my understanding of your sentence above:

"links in the actions menu are all links that manipulate something -
possibly on the context object, possibly something related to the
context object - that isn't intuitively identifiable on the page"?

And the examples below seem to re-enforce that? (ie. an action link that
forwards a bug via email?)

> context is one such thing, since it is represented by the page itself.
> 
> This implies that links /may/ disappear from the actions menu once the
> content of the pages changes. As an example scenario:
> 
>     Pristine bug, just reported. There is no content saying "This bug is
>     NOT a duplicate" on the page.  The actions menu contains a "Mark as
>     duplicate" link.
> 
>     Duplicate bug. There is content on the page that clearly says "This
>     bug is a duplicate". There is a link on that content with the text
>     "Undo this". There is no "Unmark as duplicate" link in the actions
>     menu.
> 
> I realize this is controversial; however, the alternatives are also
> controversial (no actions menu, placing links randomly -- see current
> mark as duplicate link, having links appear in menu /and/ in content),
> so I'd like us to accept to actually try this approach for 3.0 and adapt
> once we get actual user feedback.

Sounds great! I'm excited to see how this approach goes.

> 
> I will give you an example of how /I/ would like the bugs page to work:
> 
>     Pristine bug, just reported
> 
>         Actions Menu
>             - Mark bug as duplicate
>             - Convert bug to question
>             - Mentor someone to fix this bug
>             - View bug activity log
>                 (as I think the current location is random)

Sure, the current location might be random, but how does this link in
the actions menu modify the context? This one would fit in to the
'Related pages menu' though right?

>             - Add tags to bug
>                 (unless we had content that looked like this
>                     Tags: (edit)
>                  in the main page, which changed to
>                     Tags: amorphous (edit)
>                 once tags were added -- no floating Add tags link in
>                 other words)
>             - Link bug to Bazaar branch (note the branding)
>                 (again, unless there was content that said
>                     There are no Bazaar branches related to this bug
>                     (link branch)
>                  in which case there would be an obvious place to put
>                  the link)
>             - Link bug to CVE
>                 (again, similar example)
>             - This bug affects me to
>                 (unless there is a clear piece of content, for instance,
>                 filled or outlined flames indicating how many users are
>                 affected by this bug; in this case I'd put the "I am
>                 affected too!" button close to that)
>             - Forward this bug via email (yes, non-implemented feature)

And again, I don't see how this could be considered to be updating the
context object? So this type of link is interesting - and get to the
point of my confusion - it is a link for an action that does not modify
the context. So, as I understand it, it does not belong in the actions
menu, nor can it go in the "Related pages" menu. So is this the kind of
link (could be styled as a button) that must go in the main content area?

So where should the link for this feature go when it is implemented, and
why?

> 
>     I would also <noscript> the Update description/tags link, which is
>     unnecessary for JS browsers.
> 
> In summary I think this means that if there is no obvious place to put
> the link, either there's content missing or the link goes into the
> actions portlet.
> 
> For a Team page, the actions portlet would probably contain 
> 
>     Change team information
>         (details, registration.. not sure, all the words are vague)
>     Create a new poll for this team

Makes sense - as from the user's pov this i modifying the team by adding
a poll?

>     Create a mailing list for this team
>         (unless the team already has a mailing list)
>     Add new member to team
>         (In this case there /is/ related content, but I doubt people
>          adding members to team actually look at the counts of members
>          etc in https://dev.launchpad.net/TeamIndexPage when going to
>          add a member; they peck and hunt like me)
> 
> Note the use of long (but clearer) text for the links; I think it needs
> to be obvious what the link in the menu does.
> 
> Note also that Edwin asks for an example for a +edit page. Do +edit
> pages actually need actions menus? I would think they would just point
> you back to the page for the content you were +editing. 

Yep, using the " or cancel" link on the form.

> And one day,
> +edit pages will all be gone anyway!



-- 
Michael