[RCD] New look of compose and message screens

Thomas Bruederli thomas at roundcube.net
Fri Sep 14 19:24:34 CEST 2012


On Mon, Sep 10, 2012 at 8:44 AM, A.L.E.C <alec at alec.pl> wrote:
> On 09/09/2012 08:30 PM, Thomas Bruederli wrote:
>
>> I really don't see an improvement in the new
>> expand-all-options-and-headers-at-once solution you're proposing for
>> the compose screen.
>> There are several levels of "expansion" in the current compose screen
>> (so as they where in the old skin). It's common that one wants to add
>> a CC or BCC field when composing a new message. This level of
>> extensibility is perfectly covered with the (+) Add ... links we now
>> have. More advanced options are hidden in the area between headers and
>> the body. I use them way less than adding a CC. Therefore it makes
>> sense to me, to have them in a different location and hidden by a
>> separate Options button. Since they mostly affect message headers, the
>> location of this options palette is IMO just right.
>
> In my opinion in the old skin (and larry) the "Add CC" and others links
> were added because lack of vertical space, but ok. We can add these
> links back and keep new design. No problem.

The links for adding these headers was actually inspired by Gmail...
>
>> You now propose to expand everything on one click and smash a shitload
>> of options into a dummy user's face who just wants to add a CC line.
>> That's a regression and not an optimization to me.
>
> Hey, it's less clicks in the end. Why we can display all options at a
> time? Because now we have a scroller, so displaying big area of headers
> + options doesn't make the body textarea smaller. And I think this is a
> big improvement. Body textarea height is unlimited.

The number of clicks is not the only criteria for good user
experience. Showing a huge number of UI elements can easily overcharge
a user and be counter productive.

> In old skin when you
> use (show) all headers, the textarea field becomes too small.

My bad, I didn't recognize that the scrollbar changed. But what is the
minimum height of the textarea when all options are visible? It
usually scales with the window size.

> So, this and unification with the message preview was the main reason for the change.

I'm not sure if a perfect unification of all screen should be out
goal. Message viewing and composing are two distinct tasks and thus
their UIs can or even should look different. Your unconscious mind
will better understand what's on the screen (e.g. if you left your
workspace or got a phone call and then get back to your computer) if
it doesn't look absolutely the same.
>
>> As a side note, the two-step header expansion in message (pre)view
>> isn't perfect either. I was confused by the up/down arrows appearing
>> when I expanded the headers in message preview. Showing all headers is
>> again a very power-user feature and should not use the same element as
>> to just show the regular headers.
>
> But you didn't proposed a solution, you just removed the feature.

That's right, this feature wasn't foreseen in the preview mode by our
designer and I honestly forgot to add it when creating the larry
theme.
>
>> And there's no way to hide them anymore.
>
> I don't see this as a big problem, if you wanted to see them once, then
> there's a good chance you want to see them again. And really, user will
> learn very quickly how does it work.
>
>> Furthermore, I don't exactly understand why in full message
>> view mode the headers are collapsed by default. There we have enough
>> space and all basic headers should be show right away. The reason to
>> hide them in preview mode was because they're redundant to what is
>> displayed in the message list above and vertical space is limited.
>
> Answer is simple: unification (and lazyness), but we can improve this.

Again, I don't want everything totally unified but we should rather
search for the best way to display information according to the
context and the space we have available. Therefore I still propose to
show all (common) headers right away in the full message view. Using
the same UI element as in the preview mode to show all headers is fair
enough.
>
>> Overall, I'm not very happy with the changes you're suggesting or
>> which you already committed to git master. But I'd very much like some
>> more persons to speak up on this. Otherwise we'll end up in a Thomas
>> vs. Alec fight here.
>
> Yeah, I don't wanna fight, No. However I have a strong feeling I'm right
> ;) Please, look at my proposal as a concept not a complete solution. How
> does it look like when you add "Add CC", etc. buttons back and keep "the
> new look with the expander"?
>
> Here's a list of changes:
> 1. Use one big scrollable area for right side of compose screen to
> provide "unlimited" body textarea (and headers area) height.
> 2. Use design unified with the message preview - expander for compose
> options.
> 3. Move Send, Save, Cancel buttons to the toolbar.
>
> ps. Did you notice that my changes to message display screen fixed three
> tickets: #1488590, #1488538, #1488642? So, it's not just my freaky
> ideas, there's a background.

Sure, and I didn't want to criticize the fact that you fixed bugs and
closed tickets. Please don't get me wrong on this. It was just a major
change in the UI which I would have liked to be discussed, which is
what we're doing now.

In order to move this forward and tanking your proposal as a concept,
I'll do my best to present an alternative suggestion for the issues we
just discussed and agreed on in this thread.

Regards,
Thomas


More information about the dev mailing list