Re: [g-a-devel] [Usability] Mousetweaks usability discussion
- From: Denis Washington <dwashington gmx net>
- To: Jens Granseuer <jensgr gmx net>
- Cc: Willie Walker <William Walker Sun COM>, gnome-accessibility-devel gnome org, usability gnome org, Rodrigo Moya <rodrigo gnome-db org>, Vincent Untz <vuntz gnome org>, gnomecc-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: [g-a-devel] [Usability] Mousetweaks usability discussion
- Date: Wed, 31 Oct 2007 20:05:24 +0100
On Wed, 2007-10-31 at 18:24 +0100, Jens Granseuer wrote:
> On 31.10.2007 14:54, Denis Washington wrote:
> > I have made a mockup that integrates Mousetweaks settings into the mouse
> > capplet:
> >
> > http://ultimum-projekt.de/mockups/mouse.html
> >
> > I hope I haven't forgotten everything. Comments?
>
> You forgot to tell that you've made a mockup for keyboard, too:
>
> http://ultimum-projekt.de/mockups/keyboard.html
>
> And I think I'm in love. ;-)
>
> Seriously, I really like these mockups, and apart from a few minor
> easily fixable nitpicks, I think there is only one bigger issue
> (that Denis already mentioned): the Notifications window.
>
First of all, thanks for your positive yet constructive feedback. :)
> But let's do it in order (CC'ing the MouseTweaks guys, too):
>
> MOUSE
>
> Mouse
>
> * Does it make sense to have a "Mouse" tab in the "Mouse
> capplet? I'd hope all the tabs in their are about the mouse.
> Maybe "General" would be better here (same for Keyboard).
>
Yeah, naming the tabs "General" makes more sense. I just took the
headings from the current capplets for now, but I would agree to change
those labels.
> Accessibility
>
> * "Maybe we can remove the "enable mouse a11y" checkbox and
> implicitly activate the mousetweaks daemon if one of the a11y
> features is actually turned on?"
>
> I hope we can get the MouseTweaks daemon merged with g-s-d.
> That would automatically make this box unnecessary. If that
> doesn't happen, I'd agree that activating it implicitly is
> the way to go (just like it's currently done with typing
> break, fwiw).
Having MouseTweaks integrated into g-s-d would indeed be cool. That
wouldn't even mean that MouseTweaks would only work for GNOME 2.22; at
least since 2.20 g-s-d also allows third-party modules IIRC.
> * "Simulated Right Click"
>
> Does this and the related labels change when I have a
> left-handed setup? We'd either need to do that (though I
> don't know if it's even possible without having the window
> change size) or use something like the current MouseTweaks
> UI seems to do: "primary" and "secondary button". Not that
> great, either, but better than wrong, I guess.
"Simulated Secondary Button" is probably the way to go. Changing the
label depending on the mouse handness is a bad idea as this makes the
label less re-recognizable when changing from left- to right-handed.
> KEYBOARD
>
> Keyboard
>
> * "Cursor blinks in text boxes and fields"
>
> Do people know what the difference is between a box and a field? I
> know I always confuse the two. Does it matter? Can't we just shorten
> it to "Cursor blinks in text fields"?
I think the only difference is that text boxes are multi-line. But I
also think that distiguishing the two isn't necessary in this label; I'm
interested in other comments about this though.
> Layouts
>
> * The buttons without icons look odd, and different from the ones
> with icons. We should try to fix that.
IMO the text field and the "Choose..." button should go away and be
replaced with a button labeled with the keyboard model. That way it
would be kind of like a font or color chooser button.
For the "Layout Options..." button we need an icon though. I would
propose to have a generic "this button opens up an additional
preferences window" icon, like the cross referencing icon we are already
using.
> Accessibility
>
> * "Allow turning accessibility features on/off from the keyboard"
>
> "... on or off... "?
>
Maybe nicer, yet a tad longer.
> * "simultanous" is missing an "e"
Oops.
> * The "Notifications" window is bad (and contains a few typos),
> but I don't currently have an idea how to fix it, short of moving
> some of the options over to the "Mouse Keys" tab. That would
> require that we come up with a useful way to group them, plus we
> should be careful that features on one tab not affect features on
> another (turning on/off via the keyboard). To me, this is the one
> big issue that needs to be solved to make this one a winner.
As I mentioned, it's not a very good idea but the best I could come up
with. I would be glad if we found a better grouping.
> Mouse Keys
>
> * not sure I like the link to the mouse capplet
AFAIK the mouse keys feature uses some of the generic mouse options,
like pointer acceleration. That's why I think a link makes sense.
> * "Mouse Keys" tab has a "Mouse Keys" header, "Typing Break"
> (correctly, IMO) does not
We could make the top-level checkbox bold like in the Typing Break tab,
that would probably be better than a "Mouse Keys" header.
>
> Overall, great work. Thanks for persisting. ;-)
Thank you. :)
Cheers,
Denis
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]