← Back to team overview

launchpad-dev team mailing list archive

Re: RFC NavigationMenu primer

 

On Fri, Aug 7, 2009 at 6:50 AM, Christian Robottom
Reis<kiko@xxxxxxxxxxxxx> wrote:
> On Fri, Aug 07, 2009 at 10:08:57AM +0200, Michael Nelson wrote:
>> > 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"?
>
> Oh, you're right. And your sentence there is clearer than mine -- indeed
> the links there might not modify the object or something related to it,
> but perform an action with it, or render a different view for it. I
> think the examples I gave are actually the easiest way to understand
> what I mean, but Occam's razor here is "was this link placed randomly on
> the page content for lack of a better place?". No randomly placed links
> in 3.0.
>
>> >     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?
>
> Well, maybe. I'm not sure. As an end-user, would you expect to see the
> activity log as a "related page" or an action? Note that the menu
> doesn't actually say "actions menu"!
>
>> >             - 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?
>
> I'm saying that it should go into the actions menu, even though it
> doesn't modify or update anything. This is why I said I mostly agreed
> with Curtis; I think his definition is just a subset of the correct one.


It may be helpful to describe the types of actions that should appear
in the page instead of the other way around.
 * Links that edit fields on the context.
 * Links that belong in a portlet because they belong with that
subcontext object.
 * Links that append to a collection owned by the context such as
comments on a bug or milestones on a series. The subscribers list is
an exception. Since the subscribers appear in the sidebar, links for
adding subscribers will be nearby but slightly separated from the
context's action menu.

There are a few things that I don't understand about the Related Pages
menu. Why doesn't the "View activity log" belong in it? It seems
related and a non-action. I'm not sure why it's view/@@+related-pages
instead of context/@@+related-pages if we are showing/hiding the menu
by editing the template.

The wiki describes a "related <nouns>" portlet at the bottom of the
page, such as the edit pages linked from other edit pages. That used
to be in the subtabbar, and I really think it should go in the
sidebar. I only think it makes sense to put actions at the bottom of
the page if you don't really want people to use it. For example, you
want users to read all the bug comments before they add a comment.

-Edwin



References