On Aug 25, 2011, at 8: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)

I would really just make the point that most of these people seem to be trying 
to blend the contact list in. Hiding it entirely is another option. How often 
do you need something to edit versus "I want to talk to xyz person because they 
just signed on" or "I really need to talk to Bob Humphreys because he knows the 
answers to my burning question about women's taste in clothing"? I believe the 
sidebar is George's attempt to get the contact list out of the way without 
breaking it entirely for the people who have used that model for 15-20 years 
now.

The way Adam and I did it in the rawr mockups was to handle contacts more like 
safari bookmarks/history. A button in a toolbar. I'm not saying it's the best 
idea, but maybe it's worth looking into why that large percentage are really 
just trying to hide their contact list, rather than just sticking with what's 
been around forever.

>       - 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
>> 
> 

Reply via email to