launchpad-dev team mailing list archive

[Huw Wilkins <huw.wilkins@xxxxxxxxxxxxx>]

On 21/10/11 05:07, Francis J. Lacoste wrote:
> Hi Curtis,
>
> Thanks for the clarification. In other words: it doesn't matter that we
> are adding to the confusion, because the whole area is already very
> confusing, and we want to fix the whole confusion in the future by
> redoing the whole workflow.
>
> I'm still interested in Huw's opinion on the general principle though.

The general rule is one of context.

A controls should be disabled if:
- There is a way to enable the control (usually from the current page). 
E.g. the zoom in button on a map becomes disabled when the user has 
zoomed in fully. To enable the button the user first has to zoom out.
- The control is temporarily unavailable (e.g. an action is being 
completed).

A control should be hidden if:
- It is never available to the user in this context (the user can not do 
anything to enable it).

If the control is hidden it should be clear why things might be 
different in the current context (e.g. a forum thread is in "locked" 
mode). This can sometimes be supplemented with in-place messages where 
the hidden controls were, explaining their disappearance (e.g. on a blog 
post and comment form might be replaced with a message that says 
"Comments are disabled after 30 days"). These messages should be used 
sparingly and only if their disappearance is ambiguous (e.g. if a user 
can't edit items in a list there probably shouldn't be a notice where 
every edit button was).

Does that help?
> Cheers
>
> On 11-10-20 12:42 PM, curtis Hovey wrote:
> > On 10/20/2011 11:49 AM, Francis J. Lacoste wrote:
> > > As part of the disclosure project, we are removing support for
> > > multi-tenancy in bugs when privacy is involved. Simply put, if a bug is
> > > private, there can only be one bug task.
> > >
> > > That means that the 'Also affects...' actions shouldn't be available to
> > > the users.
> > >
> > > Ian has a branch that does just this: hide these actions when the bug is
> > > private:
> > > https://code.launchpad.net/~wallyworld/launchpad/one-bugtask-for-private-bugs-878605/+merge/79918
> > >
> > > There are a lot of places in Launchpad where we do this (menus for one).
> > > But it has been argued in the past that this is a source of confusion
> > > for users. "Where are these buttons gone?" and that we should instead
> > > keep the actions on that page disabled and for bonus points with an easy
> > > way to understand why the actions are disabled (tooltip, little icon,
> > > any other suggestion,)
> > >
> > > I'm asking for a definitive opinion on this matter from you :-)
> > Actually, we do not really want to do this because we do not want to
> > force users to understand how we model data. We are doing this because
> > Lp has missing and incomplete features.
> >
> > 1. There should be only one link to start the workflow to add a another
> >     affected project.
> >     AKA bug 1334
> >
> >     * There is currently two and users have to think,
> >       and many do not understand Lp's models
> >
> >     * Lp should ask the user to search and choose.
> >
> >       We do not have a vocabulary to show projects, distros, and packages,
> >       but we do have a widget that can help the user choose.
> >     * Once the user has chosen, We enter the existing workflows to add the
> >       affected project
> >
> > 2. When the bug is private, the one link starts the workflow to clone
> >     the bug and create a bug link to show the dependency.
> >     AKA bug dependencies.
> >     * The user is shown the information that will be copied and choose to
> >       redact confidential information
> >     * The user chooses the relationship:
> >       master ->  derivative
> >       master ->  duplicate
> >       depends on ->  prerequisite
> >     * The new bug is created with links to the other bug that are only
> >       visible to users with access to both bugs
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~launchpad-dev
> > Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~launchpad-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp