On Tue, Mar 29, 2011 at 23:55, David Smith <catfish....@gmail.com> wrote: > So, we were discussing the message window on IRC tonight, and in the course > of talking through a few design issues, I remembered an ooold idea that we > never did that actually doesn't seem that hard to implement: Make the message > text field float (in a fixed position) over the message view, with a css > tweak to bump the message content up so it's not obscured. I made a few > mockups by hacking up the html from smooth op 2's topic field. Obviously not > shippable at this point, but looks pretty neat nonetheless (sample content is > not intended to make sense, bits got cut out, etc…). > > http://dscoder.com/images/tabsmockup.png > http://dscoder.com/images/notabsmockup.png > > Colin suggests that the scrollbar shouldn't be all the way at the bottom like > I have it, based on his iOS experience; I just didn't feel like fixing it in > Photoshop. Various other extensions of the concept are possible (like the > "hide, but show for use" combo you can get in Safari with hide address bar + > cmd-L). > > The cool part about this (aside from just being shiny) is that it very > clearly associates the message entry field with the message view, without > needing to wrap things in borders.
I like the idea of integrating the input area into the message style, and it's a request occasionally seen in #adium. However, I think it would be bad to have the input area style *look* like it's part of the message style without actually being style author configurable. If it's not possible for the author to make the input area stylistically integrated into the rest of the message view, I'd prefer the input area use standard Mac OS X window paradigms. The mockups look pretty good with Smooth Operator (for obvious reasons) and probably would with Renkoo, but something like yMous would probably need something closer to what we have now (which is somewhat similar to yMous' topic). As for scrollbar question I don't think one size fits all. For a style with a visually "floating" input area, I think it would make sense to have a full height scrollbar to reflect the fact that you'd want the windows background to scroll across the full height of the window (for styles where the background scrolls). However, a style with an input area like I described for yMous would be best with an input area that didn't scroll. Perhaps an info.plist key to allow the style author to specify which type? It would also be nice if we would allow the style author to hide the input ares if 1) the cursor isn't over the web view, and 2) the input area does't have focus. Something like Smooth Operator would probably have the input area fade in/out while yMous would probably have the input area slide into up from the bottom. Without some sort of animation I suspect the hide/unhide would look jarring, especially in situations where the scrollbar height would change. The animation would have to be relatively fast, and it would be nice if the user could start typing before the animation was complete. -- Matthew
