Quote:
|
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.
Quote:
|
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.
Quote:
|
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.
Quote:
|
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.
Hybrid Mode
