-Cookies- How could we handle cookies instead of popping up a dialog for each cookie? We could have a panel which lists cookies associated with a site, and new cookies offered by a resource. In the current Mozilla design, this could be a sidebar, in a Mac OS X design it would probably be a drawer. When the page loads, the resource list would have the new cookies set by the page and the old cookies that were associated with the site. If the user wants to block a cookie, or delete a cookie, or modify a cookie, the user can do it by selecting a cookie and using standard editing triggers (delete key, f2 key, context menu). Why would this work? Cookies aren't interesting until their next use, which means that you have time to consider them before they're sent out again. What about cookies for embedded items? Well, Mozilla could let you hover over an item to see a preview of the cookies associated with it, and click select to keep that item active in the cookie panel. This would let you manage cookies for a link you're about to visit, or for the server which is about to send you an image. Does that really work for everything? It could if you had a special user stylesheet which was designed to show all potential resources with at least a placeholder. Note that while the easiest implementation of this feature would probably be a sidebar, it might not be the best. I'll write up some other ways to handle this context sensitive resource management in a later essay. -Images- How can we improve image management over Mozilla/4? Today we can't even easily load all images, or unload all images, so the first step would be to reach 4xp, but that's probably less than a month away, the backend support for most of it is finally in place. The basic interface would allow "show image"[4xp]/"hide image" context menuitems, a load all images button [4xp] which could turn into a hide all images button (or textonly or perhaps it could actually be the entry-point to user style sheets, and one of the style sheets would be text only, one would be load images, ...). What image management support is available in Mozilla/5 1.4? Well first, let's look at how the user can manage images in Mozilla/5. The current approach to image management has three or four mostly disconnected pieces: * You can right click an image and choose 'block images from this server', but you have no idea what server it is. * You can load an image manager from tools (Mozilla/5 1.4), which lets you remove blocked sites, but you can't add a server using the manager :). * You can choose not to load images or not to load images from foreign servers in preferences. But this option is global, and you might actually want to make the decision on a per server basis as you're browsing. Phoenix, Firebird, Mozilla/5 1.5 put the image manager into preferences next to this pair of preferences, which at least unifies these pieces. * You can't choose not to load images of a given mime type * You can't choose not to load images which are handled by plugins [a plugin might allow you to configure this, e.g. QuickTime, but Mozilla itself doesn't currently allow you to control this] * You could write CSS which styled to nothing, but there's no style sheet editor for Mozilla and it doesn't help if there's no type tag on the object. If such a rule became common it could actually encourage authors not to include type attributes for object tags, or to specify content types which don't match the actual content type of the data, which would be bad... How can we improve image management over Mozilla/5 1.4? The current approach to loading content is to try to load all resources as soon as possible. I think we can abandon this approach in favor of an approach which delays resource loading to allow the user the chance to cancel, delay or reorder resource loads. How could we do that? In the current Mozilla architecture, this would be a sidebar or part of the download manager, but as with everything else, other approaches are possible. So what would it look like? The panel would have a list of resources (images, plugin content, scripts, stylesheets, embedded content [e.g. HTML]) listed in the order in which they'll be loaded, possibly scored/colored based on things like whether the origin matches. There would be an icon for the resource which would indicate its type and whether it will load over a secure channel. If the user wants to load something sooner, the user could drag the item higher on the list, or press the plus [+] key. If the user wants to load something later, the user could drag the item lower on the list, or press the minus [-] key. To pause the loading of an item the user might press the space [ ] key or click a pause button. To prevent an item from loading the user might press the delete [del] key or click a delete button. To block or whitelist resources similar to the selected item, the user would click a block or whitelist dropdown button which would list the full server, its ancestors, and its mimetype. For an image/jpeg from classic.example.com the user would be able to block/whitelist items from classic.example.com, example.com, .com, everywhere for image/jpeg, image/* or */*. -Popups- Let's take a look at popup blocking because it's a really good example of poor UI design. What's the problem? Web sites are causing annoying dialogs. What's the Mozilla solution? *Popup* a dialog telling the user that the site wanted to popup a window. What does the user have to do in either case in order to read the original page? Close the window/dialog. What if the user is interested in the content, but not right now? Well, the modern approach to content that the user might want to read about later is to open it in a new tab, or at least predownload it so that the user could read the page when the user wanted to. How would one give the user a better experience than the annoying window/dialog? Instead of popping up anything, and instead of supplying a dialog which lists what sites tried to open dialogs, treat the pages which were going to be opened as proposed bookmarks. Any time a site tries to open a window, a bookmark is created and placed in a magic folder (which could be emptied when the browser quits). The location of the bookmark is the site the page tried to load. Description could be the page title (if prefetching is configured for blocked pages) or "Page loaded by {pagetitle} at {time}". Notes would include the url of the page that tried to load it. A small icon can appear in the status bar, as with the current popup blocking system. If the user wants to load the deferred (formerly 'blocked') page, then the user simply selects it from bookmarks (it doesn't actually have to live in bookmarks, any rdf data source which can be manipulated like bookmarks would work). Since it's a bookmark, the user could drag it to the current , load it in a new tab, load it in a new window, or do whatever one might do to a bookmark. For fun, these special bookmarks could actually appear in folders according to the site that loaded them. -History +Today +Yesterday +... +Last Week +Bookmarks Root -Suggested Pages (Deferred Pages | Blocked Links) +modern.example.com -classic.example.com *Amazon - Pyramids