Now that I'm done freaking out about single window mode ( ;) ), I agree there's
a lot to like here. Chris's suggestion is well taken, so here's what I do and
don't like:
Do:
* The use of popovers for the Me button and file transfers. It's hard for me to
say this for historical reasons unrelated to this proposal, but it's both
functional and pretty.
* More generally, the Me button in general is pretty awesome.
* Exposing more of the abilities of our text input system (emoticons, scripts,
etc…)
* The new toolbar icons are quite nice
* Elimination of the split view for message field resizing; we've had this
discussion on the list before, and I think a number of good proposals were made
(and even implemented in a branch in one case!)
Don't:
* The titlebar ain't dead. Seriously. It isn't. Pretend App Store.app doesn't
exist, it's not indicative of Lion's UI. Ask me about this again in a while.
Inconsistency aside, not using a standard titlebar (and by extension not using
NSThemeFrame) is asking for a world of hurt.
* Single window bla bla we went over this
* Popovers everywhere. This makes accessibility harder, takes more clicks, etc…
NSMenu is really pretty neat
* The whole concept of "fashion" in UIs, as well as the idea that Macs should
be like iPads. "Old" is not, by itself, "bad".
Finally, the effort and polish that has clearly gone into this mockup is
remarkable. There's some great ideas here :) Thank you
David
On Aug 25, 2011, at 6:27 PM, Evan Schoenberg, M.D. wrote:
> There is a lot to love about this proposal. Great work, George, and thank you
> for putting it together so professionally.
>
> The following is fantastic, beautifully considered, and well mocked up:
> - Title bar removal. Yes yes yes. I like moving the active chat's name into
> a sub-toolbar indicator.
> - Me button
> - Emoticon insertion
> - Scripts/links
> - Transfer activity
> - Source-target reveal behavior
> - Contact info behavior improvements as shown on page 6
> - Insertion buttons and proposed behavior
> - Character count with smart appearance behavior
> - Toolbar button redesign - looks very clean and natural
>
> Overall, I think the above should be implemented regardless of consensus on
> the single-window mode.
>
> I basically agree with David, Luke, and James' comments about the
> single-window mode:
> - Minimalist contact lists are dominant in both xtras submissions and
> in the way I've seen users configure their machines (if they configure them
> at all - I'd say about 50% are using the default setup)
> - For people who have a large number of contacts but a small number of
> active chats at any given time (which I warrant is the majority situation),
> being able to move the contact list to the side (and show/hide it on screen
> edges, in particular) without changing the message window's primacy is great.
> This has nothing to do with being borderless or not, but everything to do
> with separation of function for those who integrate Adium into a workflow
> with other apps in use simultaneously.
>
> What are y'all's thoughts on the following changes to the proposal:
>
> 1. Support opening a contact list which, by default, is the Collapsed, No
> Chats Open window. It allows display of chats in the list to be toggled
> somehow, but it does not allow expansion. It can do the sweet collapsed,
> contact selected behavior.
> - This is how it appears in Regular Window mode, that is.
> - The existing window styles are supported. In the bubbles styles, the
> always-showing search bar and bottom toolbar are dropped.
> - This window is not open when Adium starts on a fresh install. The
> Main Window is.
> - Ponder: The highly customizable contact list stuff would only apply
> when the contact list is 'torn off' into a separate window? I think so,
> because it will look terrible otherwise.
>
> 2. The Main Window behaves largely as described.
> - A button next to the 'collapse' contacts button would indicate that
> it is split off into a new window when clicked. This would collapse the
> contacts and open a Contact List window, as described above. (This makes the
> behavior easier to toggle and also more discoverable)
>
> (Eric seems to be suggesting a similar setup in the email he sent while I was
> writing this).
>
> A few other comments:
> - I feel pretty strongly that tab reordering and tearing off chats into
> independent windows should remain.
> - There's nothing about the design that prevents this; a single
> split-off chat would default to having the chat-tabs and contacts area
> hidden, but the reveal button would still work. This mirrors behavior of
> 'automatically hide tabs' in the current UI, but it's probably
> non-configurable
> - Or perhaps we intelligently follow the behavior the user did
> last - pull off a chat, then tap the reveal button, and you'll have the tabs
> and contacts visible next time you pull off a chat).
>
> - I do not think this should be a preference-level behavior (Peter's "third
> option") but rather something we sort out by letting the user interact with
> the windows.
>
> - I think this is a truly 10.7+ UI because we'd have to reinvent the wheel to
> make many of the elements happen on 10.6. That's not a deal breaker... just
> a thought.
>
> Cheers,
> Evan
>
>
>
> On Aug 25, 2011, at 4:23 PM, George Lambrou wrote:
>
>> This is a proposal I've made for Adium. However, before you go ahead and
>> open it, I'd like to ask that you look at this not as an evolution of the
>> current Adium, but simply a new Adium. Yes, it does retain many old
>> features, but at the expense of others as well. It's an idea for a new
>> direction, one with a focus on ease-of-use, simplicity, and better
>> consistency with Mac OS. It takes full advantage of Lion's new iOS-inspired
>> design direction, the perfect excuse for this kind of a clean break; as
>> such, I have not attempted to make compromises or accommodations for Snow
>> Leopard. This was created for Lion.
>>
>> Anyways, without further ado, I would like to present to you the sum of four
>> months of work, and the first step down a new road for Adium: the Main
>> Window of Adium Next.
>>
>> <Adium Next - Message Window.pdf>
>>
>> Please keep in mind that this is not 100% complete; there are still some
>> things that I haven't covered in this document, but the vast majority of it
>> is there. Any constructive comments that you may offer are greatly
>> appreciated, and I'd be happy to answer any questions you may have; thank
>> you for your time. :)
>>
>> George
>>
>
