improving the UE for content control
Myk Melez
for controlling the appearance and behavior of web content (text size,
background and text colors, popup privileges, etc.).
Two specific issues I'd like to tackle are the inability to persist some
options (f.e. text size) and the difficulty of overriding global options
(f.e. background and text colors) for specific sites or pages.
I'm also investigating extensions, greasemonkey scripts, and
bookmarklets to see if there are additional popular, high-value, and
general-purpose options that it would make sense to include in the core
product. And I'll cast a critical eye on our current set to see if
anything no longer makes sense to include.
I don't have code or a prototype yet, but I'm keen to hear feedback at
this early stage. Read on for preliminary musings on the back and front
ends, and let me know what you think.
-myk
Back End
I chatted a bit with dbaron and bzbarsky about the back end. The right
approach there may be to add a "settings" service that various layout
objects query for relevant settings at appropriate times during page load.
Storage isn't entirely clear. Global settings can probably continue to
be stored in the preferences file, while the Places annotations table
seems right for page-specific settings.
But current site-specific stuff is stored in a variety of places, like
hostperm.1 and cookperm.txt, which don't seem optimal for new settings.
Maybe there's a way to use the annotations table for this, or perhaps
it makes sense to create a new sqlite table for it.
Front End
As for the front end, it's important to note first that changing nothing
is an option. For example, even without additional UI, persisting text
size changes would be an improvement over the current state of things.
Also, I'm looking for ways to improve control for average users dealing
with common web annoyances. Power users are the usual constituency for
"control" and "configuration", and I'm keen to accommodate them where
possible, but not at the expense of an interface that regular users can use.
With all that in mind, one idea I've been considering recently is a
"content control" panel with controls for common options. The panel
would distinguish between global and site/page-specific settings and let
users change those settings for the pages they browse.
My first thought is to put the panel into a sidebar hooked up to an item
in the Tools menu. When active, the sidebar would reflect the settings
for the current site/page as users browse from page to page (including
switching tabs).
Another option is to put the panel into a page-specific dialog box like
the Page Info window. Something similar is already happening in the
patches on bug 339102.
But dialogs add window management excise, and page-specific UI makes it
harder to make a change to several sites/pages in a row, which I expect
to be a common use case. So a sidebar seems better.
Adam Kowalczyk
but I think the UI should be as lightweight as possible. The key
question we must answer before we can pick the best UI is how many
settings do we want to enable. Perhaps we should set up a wiki page for
brainstorming what kinds of settings could be provided.
I tend to think that Page Info dialog isn't a good point of integration.
It's too cumbersome for normal users with all those tabs and
incomprehensible terms and tables. However, I recall some people were
thinking about redesigning and simplifying it, in which case it may be
worth consideration to put the content control settings there.
The sidebar seems to heavy for me. Ideally, these features should be
"invisible" while this would create a whole new "configuration panel".
This isn't very appealing.
My idea is to integrate the most essential features in the View menu
which would be the primary integration point. If the geeky Page Info
dialog is to be redesigned then perhaps we can also collect the settings
there for those who need to configure a couple of things at once and
for easier viewing of the current configuration.
However, the point is keep the number of settings low. I think the back
end API should be much more powerful so that extensions can easily
enhance the level of control but the core product should provide only
the most essential and common options.
- Adam
Gervase Markham
> But current site-specific stuff is stored in a variety of places, like
> hostperm.1 and cookperm.txt, which don't seem optimal for new settings.
We've been trying to get rid of cookies.txt for ages, so we can expand
the format to allow things like HTTPOnly cookies.
> My first thought is to put the panel into a sidebar hooked up to an item
> in the Tools menu. When active, the sidebar would reflect the settings
> for the current site/page as users browse from page to page (including
> switching tabs).
>
> Another option is to put the panel into a page-specific dialog box like
> the Page Info window. Something similar is already happening in the
> patches on bug 339102.
I think it's powerful to be able to see the changes happen as you make
them, so the sidebar makes more sense.
Gerv
Peter Kasting
> I like the idea of leveraging global and site-specific content control
> but I think the UI should be as lightweight as possible.
I agree completely.
I want UI features to answer the question of how they serve the needs
of, and are usable by, "normal" users. The very same people who have
the most difficulty reading pages today are the ones who will likely be
least able to cope with a heavyweight, feature-filled UI.
IE7 keeps things fairly simple by promoting full-page zoom as the main
accessibility enhancement, and making the UI to get at it reasonably
small. However, could we do even better? Various folks (hixie, dbaron,
others?) have proposed methods for auto-selection of text size/zoom
level per site, simplifying the font controls in the control panel, etc.
An interface with no buttons is simpler than an interface with one.
I'm all for giving the browser the ability to do lots of complex stuff
(especially so extensions can expose it), but in the base product, if I
have to hit multiple buttons and choose several different controls, or
type in site names, _I'm_ not going to be able use this, let alone many
of our less-technical users.
PK
Mark Finkle
size, background and font colors. If it's to create a more accessible
experience, then it sounds like a worthy cause. If it's to allow good'ole
tweaking, then I'd say keep it out of the base product.
If we're talking about accessibility, then can't we create some a simple
sidebar (for example) that allows the user to pick from several canned
"schemes" that set multiple options at once (under the covers). The user can
pick the "scheme" that best suits their needs and they're done. I am
defining a "scheme" as a combination of textsize and background/font
contrast, but it could also include things like text-only vs images; easy to
see <A> links and popups for accelerator keys.
I agree with PK, presenting too many controls and options will not help
users who need a better experience.
Mark Finkle
"Peter Kasting" <pkas...@google.com> wrote in message
news:mailman.693.1163179181...@lists.mozilla.org...
Myk Melez
> I like the idea of leveraging global and site-specific content control
> but I think the UI should be as lightweight as possible.
I agree.
> The key
> question we must answer before we can pick the best UI is how many
> settings do we want to enable. Perhaps we should set up a wiki page for
> brainstorming what kinds of settings could be provided.
Yup, we've been doing that:
> I tend to think that Page Info dialog isn't a good point of integration.
> It's too cumbersome for normal users with all those tabs and
> incomprehensible terms and tables. However, I recall some people were
> thinking about redesigning and simplifying it, in which case it may be
> worth consideration to put the content control settings there.
Folks have been working on a simplified Page Info dialog over in bug
339102, and the redesign does include a Permissions panel with some
content control settings.
https://bugzilla.mozilla.org/show_bug.cgi?id=339102
But I'm inclined to think that a sidebar is preferable to a dialog for
these kinds of settings, since it can be context-sensitive (i.e. show
the settings for the site the user is currently browsing) and it doesn't
exact a window management penalty.
> The sidebar seems to heavy for me. Ideally, these features should be
> "invisible"
Indeed, ideally content authors should get content right, and Firefox
should automatically fix things when they don't, rendering content
control unnecessary or invisible to the user.
But when we fall short of that ideal, as we are wont to do in this
suboptimal world, it's useful for there to be simple, easy to use
mechanisms for users to take matters into their own hands.
> while this would create a whole new "configuration panel".
Well, we have a "configuration panel" already in the Preferences window.
But it isn't context-sensitive, which makes its UI significantly more
cumbersome to use.
Try adding a site to the list of sites allowed to load images in
Preferences > Content to see what I mean. If we put such a feature on a
context-sensitive content control sidebar (and I'm not saying we would,
just using it as an example of a site-specific setting), then invoking
it for a particular site would be a single click.
> My idea is to integrate the most essential features in the View menu
> which would be the primary integration point.
The View menu is useful, but menus have a pretty limited interaction
vocabulary, and it's unlikely that we can provide the best experience
solely through a menu.
> However, the point is keep the number of settings low. I think the back
> end API should be much more powerful so that extensions can easily
> enhance the level of control but the core product should provide only
> the most essential and common options.
I agree 100%.
-myk
Myk Melez
> I want UI features to answer the question of how they serve the needs
> of, and are usable by, "normal" users. The very same people who have
> the most difficulty reading pages today are the ones who will likely be
> least able to cope with a heavyweight, feature-filled UI.
Sure, and that's where I'm coming from, too. I'm not suggesting
something heavyweight or feature-filled. Quite the opposite, in fact.
> IE7 keeps things fairly simple by promoting full-page zoom as the main
> accessibility enhancement, and making the UI to get at it reasonably
> small. However, could we do even better? Various folks (hixie, dbaron,
> others?) have proposed methods for auto-selection of text size/zoom
> level per site, simplifying the font controls in the control panel, etc.
> An interface with no buttons is simpler than an interface with one.
Agreed. And if we can figure out how to auto-select the right text
size/zoom level, then there's no need to expose UI to the user for
manually handling that chore.
But for common web annoyances that we can't automatically fix (and I
suspect there will always be some of those), there is value to enabling
our users to fix them, and there is value in making those tools
available to average users.
> I'm all for giving the browser the ability to do lots of complex stuff
> (especially so extensions can expose it), but in the base product, if I
> have to hit multiple buttons and choose several different controls, or
> type in site names, _I'm_ not going to be able use this, let alone many
> of our less-technical users.
Right, and one of the purposes of the sidebar is to reduce the number of
controls you have to click/select/activate to get content control stuff
done and to obviate the need for you to manually enter site names. If a
sidebar makes things more complicated, then it's the wrong approach.
-myk
Myk Melez
> Maybe we should be asking why a user wants to mess with options for text
> size, background and font colors. If it's to create a more accessible
> experience, then it sounds like a worthy cause. If it's to allow good'ole
> tweaking, then I'd say keep it out of the base product.
My focus is on settings which improve the web experience and mitigate
common web annoyances, not tweaking for its own sake or for fun.
> If we're talking about accessibility, then can't we create some a simple
> sidebar (for example) that allows the user to pick from several canned
> "schemes" that set multiple options at once (under the covers). The user can
> pick the "scheme" that best suits their needs and they're done. I am
> defining a "scheme" as a combination of textsize and background/font
> contrast, but it could also include things like text-only vs images; easy to
> see <A> links and popups for accelerator keys.
It's possible, although schemes add complexity, not only for scheme
management but also conceptually, since they establish an additional
level of abstraction.
They're also hard to get right, and they make things harder the first
time a user wants to apply a scheme with exceptions.
I suspect we're better off starting with a small set of discrete
controls and then consider schemes as an additional layer if experience
shows that users find themselves applying the same settings repeatedly
and that doing so is inordinately burdensome.
> I agree with PK, presenting too many controls and options will not help
> users who need a better experience.
I agree with Peter, too; the less UI the better, and Firefox should
automatically adjust content when we know it serves the user's interest.
But we can't know that all the time, so there's still a place for UI
which enables user control over content. And I think there's ample room
for improvement in our current version of that UI (scattered across the
View menu, several Preferences panes, and the context menu).
-myk
Mark Finkle
something similar), but there is an accessiblilty section in Control Panel
that has various options for individual control over Sounds, Mouse, Display
and others. In the Display area there are several "high contrast" modes a
user can pick. The modes effect colors (text and background) and text size.
In IE, it also effects display of images.
It could be used to draw ideas. Also note that IE respects the settings
(chrome and content) while Firefox only changes it's chrome. The content is
unaffected.
I still like 'schemes' as a first line and individual control as a second
(deeper in UI) level.
Mark Finkle