[FredH]

Originally Posted by BwanaZulia

- Integrate some of the best features of Firefox Extensions like Web Developer, X-ray, Measure It, Google Notebook, Sage and Extended Status Bar (great stuff there).

That's really how you're going to add value IMO, if you can incorporate some of this stuff in a Cocoa browser and avoid bloat (sounds easy!). But I'm speaking as an interested non-OW user.

[Stormchild]

Originally Posted by earthsaver

The answer to auto-update desires, of course, is Sparkle. Adium X 1.0 uses it, btw.

Agreed. Sparkle is excellent.

[Stormchild]

Some of the items on my list:

General

• When pointing at a bookmark in any menu, show a tooltip with the contents of the "Note" field after a short delay. One thing I use the notes for is to list the products that a Mac software company makes, so that I can search for the product if I forget what company makes it (or remember why I bookmarked a particular company).
• Status bar should indicate whether a link will open in the current tab, a new tab, or a new window. Tell me what's going to happen when I click a link. I don't like surprises. (Honestly this should already be in the current version; Safari does this.)
• As suggested in another thread, sort the history list by when a page was closed (closed the tab or URL changed), not when it was opened. This will make it much easier to get back to a page when a tab is accidentally closed.

Single Window Mode

• Preference to open all target="_blank" links in a new tab. This seems to be the right way to stop links from opening in new windows. I don't want to redirect *all* of those to new tabs; when JavaScript is used to open a popup to show an enlarged image or quick dialog, I certainly don't want that in a new tab. As for distinguishing between JavaScript links that just open a small window vs. actually link to another full page, this could be determined by whether or not it's set to hide the toolbars. If it's not hiding the toolbars, it's probably a link to another site, in which case it should be forced to open in a new tab instead.
• The "Open All In Tabs" feature for updated bookmarks/RSS feeds should open the tabs in the current window, not a new one (at least, make it optional). This is already the behavior when opening multiple bookmarks in tabs; I don't know why the same command in the Dock menu behaves differently.

Inspector Gadgets

• Use those wonderful OmniPalettes to implement Downloads, Search Shortcuts and Workspaces as inspectors.
• In addition to Page Info and Bookmark Info, use the larger in-window inspector for managing Cookies and Blocked URLs (rather than opening sheets for these).
• This one's up for debate, but I think the Site Preferences could be done as an inspector palette as well, instead of using the larger in-window inspector.
• DOM Inspector could certainly be an inspector palette, but it might be best just to use the WebKit one "as is" so that you don't have to mess around to incorporate the latest version every time they update it.

Tabs

• Get rid of the drawer, and put the tabs in an iTunes-style sidebar on the left. Perhaps this should be optional, in case anyone wants to keep the drawer for some reason. There should be a button to hide/show the tab sidebar, and if we do keep the drawer, just use the same toolbar button to hide/show the sidebar or drawer, depending on which is selected.
• Organize tabs from the same site into a group that can be collapsed/expanded.
• Keyboard shortcut to force a link to open in the current tab.
• Never create a new tab when there's an empty one already available. If there's an empty one, use it. For example, when a URL is launched from another app.

Forms

• Forms auto-fill that actually works. Safari's autofill works brilliantly (worked well in IE 5 too). This feature never worked very well for me in OW. Half the fields don't get filled in.
• Auto-save (to local temporary files) while typing in a textarea. I've gotten into the habit of regularly selecting all the text and dragging the clipping to my desktop in case the browser crashes or I accidentally close the window (or whatever else) when typing a long forum reply. I don't use web email myself, but lots of people do, and would find this very handy here too. For bonus points, auto-save the entire state of the form. Some thought would have to be put into deciding what forms this should apply to (since sometimes a "form" is just a simple drop-down menu). It should probably at least include one text field. Doing this once a minute would be good (starting one minute after the user makes the first change to a form field) -- this would avoid autosaving the text from every little search field. When returning to a form for which an auto-save state exists, a dialog (sheet) should ask the user if they want to restore the form. Submitting a form would clear away any auto-saved states for it, so we'd only be asking if the user started filling out a form, but never submitted it.

I'm sure I can think of plenty more.

[JKT]

That's a reasonable summary of a number of other people's requests.

Btw - OmniWeb already does show you what is going to happen when you click a link, except it only does it if you are command-(shift)-clicking it. I agree that this needs to be extended to show you what will happen when you perform a normal click.

The sidebar versus drawer thing has already been thrashed out in other threads (note that one was in the OmniOutliner forum, but the advantages a drawer offers are the same in OmniWeb, with a few additional ones to boot) - I really hope we don't get dicked by only having a sidebar. The drawer has a number of advantages that a sidebar does not. A sidebar has absolutely none (other than aesthetic appeal and that is in the eye of the beholder).

Auto-saving text input. This always used to happen in 5.1.3 and earlier if I had the Always save forms for autofill selected - if OmniWeb crashed, when I restored it, my text input in forums was also restored 90% of the time. However, with the way this particular forum works (having to click the Quick reply or Quote button) this no longer occurs in 5.5. Having it save to a temp file sounds appealing. However, in both the autofill and temporary text input save there is a security issue. Passwords and e.g. Credit card numbers should not be saved (I would like to see a setting to exclude numbers from the Autofill and Autocomplete memory).

[Stormchild]

Originally Posted by JKT

That's a reasonable summary of a number of other people's requests.

I'm sure some of my requests have already been suggested by others, but those were really just my own thoughts. I haven't dug around and looked at all the ideas people have already discussed elsewhere on the board.

Originally Posted by JKT

Btw - OmniWeb already does show you what is going to happen when you click a link, except it only does it if you are command-(shift)-clicking it. I agree that this needs to be extended to show you what will happen when you perform a normal click.

Yeah, although it's a bit wonky in the current beta (5.5b3). You have to hold the modifier(s) before pointing at the link; the status bar no longer updates "live" as you press or release modifer keys.

Originally Posted by JKT

I really hope we don't get dicked by only having a sidebar. The drawer has a number of advantages that a sidebar does not. A sidebar has absolutely none (other than aesthetic appeal and that is in the eye of the beholder).

I'd be interested in hearing your thoughts on what advantages a drawer offers that a sidebar doesn't. Some thoughts on the matter:

• A drawer is a little bit shorter than the total window height, and has a bit of empty space above and below it (so you can see a bit of what's underneath). I actually don't like this, myself, but some people might.
  
• Depending on the combined height of your toolbar, address bar (if you've got the separate one enabled), and bookmarks bar, the drawer may offer more vertical space than a sidebar (which would be the same height as your viewport). On the other hand, when you hide your toolbars, a sidebar would have more vertical height. In my case, since I generally want my toolbars visible, a drawer would normally have more vertical space (with my settings, it's about an extra 65px).
  
• When you click to show the drawer, the window will move if necessary, to accomodate the necessary width, and move back when you hide it again. Some people might like this behavior (I see some merit to it). I find it annoying, and I always make sure drawers are positioned such that my windows will never move around when hiding or showing them.
  
• A drawer can be resized without changing the width of the viewport. When adjusting the width of a sidebar, the viewport would grow and shrink accordingly (meaning you might also have to resize the overall window as well). I never resize my drawer, but if anyone does this regularly, they would probably be better-served by a drawer.
  
• A drawer can be positioned on the left or the right side of the window. A sidebar can really only be on the left (and should be anyway).

I think you're right, actually. There are several good arguments in favor of the drawer, and it should definitely stick around. I just prefer the integrated look of sidebars vs. drawers, and would appreciate having it as an option. It's not a matter of mere aesthetics to me, and IMO form and function are inseparable. The cleaner and simpler a design is, the more functional it is to me. For example, when text is set in a larger font with more spacing between the lines, it's a great deal easier for me to read it, and to me is worth the cost of not being able to fit as much text on one page.

When the current iTunes-style sidebar -- distinguished by its light blue background instead of being surrounded by thick borders and bevels -- made its way into Mail, it made the experience of using Mail noticeably more enjoyable (which is entirely subjective, of course, but nonetheless a reality for me). Drawers have a lot more visual "noise"; thick border, beveled inset, striped background, drop shadow cast by the main window, and in the case of OW, a second, inset white content area, with another border, and gaps between that and the edges of the drawer. The gaps around the outside of drawers are not to my liking either; it's not useful to me to see a little slice of whatever happens to be behind it, and for me it's just another source of visual noise.

My point is that some may prefer the cleaner, integrated look and feel of a sidebar, at the expense of the flexibility that the drawer offers. Having it as an option would be much appreciated by those people, while leaving the current functionality in place for those who like it the way it is.

Originally Posted by JKT

Auto-saving text input. This always used to happen in 5.1.3 and earlier if I had the Always save forms for autofill selected - if OmniWeb crashed, when I restored it, my text input in forums was also restored 90% of the time. However, with the way this particular forum works (having to click the Quick reply or Quote button) this no longer occurs in 5.5. Having it save to a temp file sounds appealing. However, in both the autofill and temporary text input save there is a security issue. Passwords and e.g. Credit card numbers should not be saved (I would like to see a setting to exclude numbers from the Autofill and Autocomplete memory).

I'm actually not talking about autofill or autocomplete though (I guess the "auto-" prefix "auto"matically suggests a relationship between those features). I'm just talking about a safety net so you don't lose what you're working on when you're typing in a particular form -- particularly web-based mail, forums, and content management systems. For the sake of security, there are a couple of options. Your suggestion to not record fields consisting of only numbers (and possibly hyphens) is a good one. Another approach would be to only autosave textareas, as that's what I'm primarily concerned about losing. Anything that fits in a single-line text field can't be that hard to type in again. But I don't want to lose, for example, one of my 3 page rambles about what Omni should do with the next version of their browser, because...well, maybe that's not a good example.

As for autocompletion, I've found it more irritating than helpful to have OW saving everything I ever type into a form and suggesting it when I try to fill out other forms. I don't like that at all, and turned it off pretty quickly.

[Len Case]

Originally Posted by Stormchild

I'm just talking about a safety net so you don't lose what you're working on when you're typing in a particular form -- particularly web-based mail, forums, and content management systems.

Workspaces already store form imputs as part of history (including the current page). Unfortunately, WebKit clears the forms on the current history node when loading workspaces because they are being reloaded (to prevent stale data). If you load the workspaces from the cache, the form ought to be restored including typing in textareas.

 defaults write com.omnigroup.OmniWeb5 WorkspacesLoadFromCache -bool true

alternatively, you can try going back and then forward in history.

[JKT]

Originally Posted by Stormchild

I'd be interested in hearing your thoughts on what advantages a drawer offers that a sidebar doesn't. Some thoughts on the matter:

• A drawer is a little bit shorter than the total window height, and has a bit of empty space above and below it (so you can see a bit of what's underneath). I actually don't like this, myself, but some people might.
  
• Depending on the combined height of your toolbar, address bar (if you've got the separate one enabled), and bookmarks bar, the drawer may offer more vertical space than a sidebar (which would be the same height as your viewport). On the other hand, when you hide your toolbars, a sidebar would have more vertical height. In my case, since I generally want my toolbars visible, a drawer would normally have more vertical space (with my settings, it's about an extra 65px).
  
• When you click to show the drawer, the window will move if necessary, to accomodate the necessary width, and move back when you hide it again. Some people might like this behavior (I see some merit to it). I find it annoying, and I always make sure drawers are positioned such that my windows will never move around when hiding or showing them.
  
• A drawer can be resized without changing the width of the viewport. When adjusting the width of a sidebar, the viewport would grow and shrink accordingly (meaning you might also have to resize the overall window as well). I never resize my drawer, but if anyone does this regularly, they would probably be better-served by a drawer.
  
• A drawer can be positioned on the left or the right side of the window. A sidebar can really only be on the left (and should be anyway).

<snip>

A few more advantages to the drawer which comes from my experience with Safaristand:

1. Because a placeholder is already present for it, when the number of tabs exceeds the vertical height of the drawer, the appearance of a scrollbar does not cause the tabs to resize and become smaller (use Safaristand or Mail to see how annoying this is with a sidebar where the scrollbar and placeholder for it only appears once you exceed the vertical height - this is something that would happen a lot in OmniWeb if you use the page info or site specific preferences pane very much).
2. Because of the gaps at the top and bottom of the drawer, it is easier to both see and to drag and drop to targets behind the window and to bring targets from the rear to the front (not such a big advantage owing to Exposé but it is one nonetheless).
3. You're no. 2 isn't right - if you hide the toolbars, a sidebar would not offer you more vertical height than a drawer as the buttons for switching between tabbed and list view and the action menu would still be present, as they are in the drawer. All it would do is make it offer the same vertical height that the drawer already has. There is only one instance when a sidebar could offer more height and that is when you hide both the toolbar and the status bar.
4. What is implicit in your no. 3 is that you can resize and close a drawer without any impact on the content of the window (with the exception of the extreme situation where your window is near or full screen and the window has to resize to accommodate the drawer). With a sidebar, the content of the window would have to reflow with every single adjustment you make to it, no matter what size your window is.

IMO, the sidebar is only functional for applications where the content is static 90 to 100% of the time which is why it works for iTunes and (almost) works for Mail (it doesn't if you are opening and closing folders which cause the content of the sidebar to exceed the vertical height). FWIW, I much preferred it when sidebars had a distinctive border and I really do not like the way they are now in 10.4 with practically zero distinction between them and the main content - to my mind that was a loss of function purely for the sake of form.

I have now remembered the one advantage that a sidebar does have for me - it can't become detached from the window when you use Exposé, which is something that sometimes happens to me when I use OmniWeb and exposé as I switch workspaces (I sometimes catch it while the drawer opens, and it detaches from the main window during the exposé process - you have to do a hide/show to get it back).

[Stormchild]

Originally Posted by JKT

Because a placeholder is already present for it, when the number of tabs exceeds the vertical height of the drawer, the appearance of a scrollbar does not cause the tabs to resize and become smaller (use Safaristand or Mail to see how annoying this is with a sidebar where the scrollbar and placeholder for it only appears once you exceed the vertical height - this is something that would happen a lot in OmniWeb if you use the page info or site specific preferences pane very much).

This is a good point. However, I think it would be relatively trivial to put the same placeholder in the sidebar. It might look a little odd though; I'd have to see a mockup. As for the page info and site prefs, in my mind the pane would continue to open as part of the content area only, not appear under the sidebar as well.

Originally Posted by JKT

With a sidebar, the content of the window would have to reflow with every single adjustment you make to it, no matter what size your window is.

Yeah, as I mentioned, if you like to resize your tab area, you'll probably prefer the drawer. In my case, not only do I never resize the drawer, it annoys me when it gets resized accidentally (because it actually accepts click-drag input along any of its edges, not just the part that's supposed to be draggable). It's even possible to click and drag in a hairline area where the window and tab meet, and end up resizing the drawer instead of whatever you meant to do (you could have been trying to grab the scrollthumb for the main window, or move one of the tabs around). I've got my tab drawer set at the exact width at which 5 tabs will fit without needing a scrollbar. Whenever it gets accidentally resized, I have to make sure I have exactly 5 tabs open (create empty ones or close some), then drag it around to get it to the right place again.

Coming back to the main point (how do those keep getting away from me?), for someone who likes to set things up a certain way and then keep it like that, the issues of resizing a sidebar would never be a problem.

Originally Posted by JKT

IMO, the sidebar is only functional for applications where the content is static 90 to 100% of the time which is why it works for iTunes and (almost) works for Mail (it doesn't if you are opening and closing folders which cause the content of the sidebar to exceed the vertical height).

What doesn't work about it? When I open enough folders in Mail that the sidebar gets a scrollbar, it doesn't bother me at all. I don't see what's different between that, and having a scrollbar in a drawer. As long as the sidebar doesn't look weird with a scrollbar placeholder (I think they're called "hints" actually), there would be no functional difference whatsoever with a drawer in that regard.

Originally Posted by JKT

FWIW, I much preferred it when sidebars had a distinctive border and I really do not like the way they are now in 10.4 with practically zero distinction between them and the main content - to my mind that was a loss of function purely for the sake of form.

The blue background makes it very clearly distinct, IMO, and the lack of border increases the usable area of the sidebar. I welcomed this change when it first appeared in iTunes, as it allows more space for longer playlist names (and helps make up for the indentation of items in folders, which were added in the same version IIRC).

In fact, the lack of horizontal space for tab names is probably the most-criticized aspect of Omni's tab implementation (this isn't a sidebar vs. drawer thing though; a sidebar wouldn't help if we just put the same tabs there). Maybe OW's tab thumbs shouldn't be fixed at 4:3. The problem is, if you want to make your tab names longer, you must also reduce the number of tabs you can see at once. It would be nice if there was some way to make the tabs wider without also making them taller.

Originally Posted by JKT

I have now remembered the one advantage that a sidebar does have for me - it can't become detached from the window when you use Exposé, which is something that sometimes happens to me when I use OmniWeb and exposé as I switch workspaces (I sometimes catch it while the drawer opens, and it detaches from the main window during the exposé process - you have to do a hide/show to get it back).

True, and I've also seen drawers get detached when switching desktops in some of the virtual desktop programs. These are just bugs that need to be fixed (and/or shortcomings that need to be addressed), and not so much a problem with the concept of drawers in general.

You've made some good points here, and I would certainly agree that the drawer should be left in. To be honest, I'd have to at least see a mockup of how a sidebar would look before I could say which one I'd actually prefer in real life. I could have probably done one by now if I'd not spent all this time yammering about it!

[JKT]

Originally Posted by Stormchild

This is a good point. However, I think it would be relatively trivial to put the same placeholder in the sidebar. It might look a little odd though; I'd have to see a mockup. As for the page info and site prefs, in my mind the pane would continue to open as part of the content area only, not appear under the sidebar as well.

Not trivial at all as no sidebars in the OS have one - it would have to be hand coded and does not come for free from the OS.

Yeah, as I mentioned, if you like to resize your tab area, you'll probably prefer the drawer. In my case, not only do I never resize the drawer, it annoys me when it gets resized accidentally (because it actually accepts click-drag input along any of its edges, not just the part that's supposed to be draggable). It's even possible to click and drag in a hairline area where the window and tab meet, and end up resizing the drawer instead of whatever you meant to do (you could have been trying to grab the scrollthumb for the main window, or move one of the tabs around). I've got my tab drawer set at the exact width at which 5 tabs will fit without needing a scrollbar. Whenever it gets accidentally resized, I have to make sure I have exactly 5 tabs open (create empty ones or close some), then drag it around to get it to the right place again.

FWIW, you can just restore your Workspace snapshot to recover the size of your drawer. I must confess this was something I had never noticed about drawers (that they resize no matter what edge you drag). Personally, I very rarely resize my tabs/drawer either, but I do show and hide it and in this instance it has the advantage of being independent of the main window content.

Coming back to the main point (how do those keep getting away from me?), for someone who likes to set things up a certain way and then keep it like that, the issues of resizing a sidebar would never be a problem.

That's assuming you don't accidentally resize it the way you do with your drawers :p

What doesn't work about it? When I open enough folders in Mail that the sidebar gets a scrollbar, it doesn't bother me at all. I don't see what's different between that, and having a scrollbar in a drawer. As long as the sidebar doesn't look weird with a scrollbar placeholder (I think they're called "hints" actually), there would be no functional difference whatsoever with a drawer in that regard.

It has the same flaw as Safaristand of content in the sidebar being lost/shortened due to the addition of a scrollbar.

The blue background makes it very clearly distinct, IMO, and the lack of border increases the usable area of the sidebar. I welcomed this change when it first appeared in iTunes, as it allows more space for longer playlist names (and helps make up for the indentation of items in folders, which were added in the same version IIRC).

Good point about there being more room, but the consequence is that there is a miniscule target for resizing the sidebar - I guess the longer names is more important, but again this is because iTunes has a relatively static list etc. FWIW, the blue background is pretty indistinct on my PowerBook LCD. I can increase its visibility by screwing up my Colorsync settings, but that is not at all desirable. Apple could solve this by making the colour more distinct, but then it starts getting ugly.

In fact, the lack of horizontal space for tab names is probably the most-criticized aspect of Omni's tab implementation (this isn't a sidebar vs. drawer thing though; a sidebar wouldn't help if we just put the same tabs there). Maybe OW's tab thumbs shouldn't be fixed at 4:3. The problem is, if you want to make your tab names longer, you must also reduce the number of tabs you can see at once. It would be nice if there was some way to make the tabs wider without also making them taller.

They could also move the x for closing onto the tab image itself a la Safaristand which would give more room for titles.

True, and I've also seen drawers get detached when switching desktops in some of the virtual desktop programs. These are just bugs that need to be fixed (and/or shortcomings that need to be addressed), and not so much a problem with the concept of drawers in general.

Something for Apple to fix if they can be bothered, but I suspect that OmniGroup aren't even going to have the option of retaining drawers in the future as Apple is probably going to ban them.

You've made some good points here, and I would certainly agree that the drawer should be left in. To be honest, I'd have to at least see a mockup of how a sidebar would look before I could say which one I'd actually prefer in real life. I could have probably done one by now if I'd not spent all this time yammering about it!

Try using Safaristand for a while if you haven't already.

I think I'll make this my last post on the subject as I've hijacked the thread! ;)

[Forrest]

This thread has taken off a little more than mine on the same topic, so I'll just link in my thoughts: http://forums.omnigroup.com/showthread.php?t=624