On Mar 30, 2011, at 8:50 AM, Matthew wrote:
> 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
>
We discussed this some; the general thinking is that losing the niceties of
NSTextField is not worth it for styleability, *but* that it might well be
possible to fake it by having the text field be in a known location and notify
the message view of size changes, allowing the message view to stick an element
under it. While a bit of a hack, I think either that or a *very* minimal "text
field with a shadow" are the way to go. A chrome-heavy look like I have in the
mockup obviously isn't suitable to all styles.
David
