In last few changes I improved message display screen. So, now it looks the same as the preview frame. I think this way the UI looks more clean and unified. I hope you agree with me. This also matches the look of other tasks e.g. addressbook where white color is used for the whole contact information frame/box.
Because I was never happy with that how mail compose screen looks like, the idea came to make the same with compose screen. I started to work on this. See attached screenshot. The main reason of this change is a unification, but it will fix some issues on compose screen. E.g. the whole compose box will be scrollable so there will be no problems with too small screen height (even with displayed all headers and options).
Opinions?
On 04/09/2012 13:33, A.L.E.C wrote:
In last few changes I improved message display screen. So, now it looks the same as the preview frame. I think this way the UI looks more clean and unified. I hope you agree with me. This also matches the look of other tasks e.g. addressbook where white color is used for the whole contact information frame/box.
Because I was never happy with that how mail compose screen looks like, the idea came to make the same with compose screen. I started to work on this. See attached screenshot. The main reason of this change is a unification, but it will fix some issues on compose screen. E.g. the whole compose box will be scrollable so there will be no problems with too small screen height (even with displayed all headers and options).
I personally don't like a pure white background. It is also disability unfriendly where slight grey/slight blue/slight green or slight pink would be preferable - is there an option to perhaps add an option in the database (i.e. make it user specific) for disability friendliness? It could make it white by default but change it per user if that user found a specific colour better suited to their visibility.
I know that there is software that helps under Windows (like it or loath it) but as far as I know, there is none really that helps under Macs and I don't really know about Linux/Unix boxen (never looked into it).
Thanks,
Jan M. Dziewulski ACA, ACMT, ACTC, ACSA
A.L.E.C wrote:
In last few changes I improved message display screen. So, now it looks the same as the preview frame. I think this way the UI looks more clean and unified. I hope you agree with me. This also matches the look of other tasks e.g. addressbook where white color is used for the whole contact information frame/box.
Because I was never happy with that how mail compose screen looks like, the idea came to make the same with compose screen. I started to work on this. See attached screenshot. The main reason of this change is a unification, but it will fix some issues on compose screen. E.g. the whole compose box will be scrollable so there will be no problems with too small screen height (even with displayed all headers and options).
Opinions?
I like the old/current screen better because it brings a better separation of the different parts (headers, compose text, options). We already had feedback from a usability expert, that the gray arrow to expand the headers in the preview frame is not intuitive and I think we should therefore not copy that into the compose screen. And where can I now add CC, BCC and stuff?
Improvement of the current compose screen could be:
- Add toolbar buttons for send/save/cancel and move the current form
buttons to the bottom of the screen. That's what we have in the classic skin and it respects the top-to-bottom flow one might have when composing a message.
- The white compose area (especially in plain text mode) could get of a 3D
inset border in order to make it more appear as a place where one can enter text.
~Thomas
On 09/05/2012 04:14 PM, Thomas Bruederli wrote:
I like the old/current screen better because it brings a better separation of the different parts (headers, compose text, options). We already had
But my way it just looks the same as in message preview. The interface becomes more intuitive when unified. Why not make message compose looks the same as message preview?
feedback from a usability expert, that the gray arrow to expand the headers in the preview frame is not intuitive and I think we should therefore not copy that into the compose screen. And where can I now add CC, BCC and stuff?
Additional headers and options would be displayed when you click on this "not intuitive expander" ;) It's just me who thinks that current compose screen in Larry just looks ugly?
Improvement of the current compose screen could be:
- Add toolbar buttons for send/save/cancel and move the current form
buttons to the bottom of the screen. That's what we have in the classic skin and it respects the top-to-bottom flow one might have when composing a message.
In my opinion we don't need more buttons, but current buttons should be moved to the toolbar for sure.
Is community not interested in the discussion? I'm waiting for more opinions.
I prefer the proposed new look&feel instead of the current Larry variation. It's indeed more intuitive and results more cleaner interface. I really like it's simplicity and for me that "gray arrow thing" is just fine. But if need arise we may improve it by either creating nice mouseover highlight for it, or by auto expanding it on mouseover and auto collapsing it (but only the non customized fields) on mouseout.
Barna
On 2012-09-05 19:16, A.L.E.C wrote:
On 09/05/2012 04:14 PM, Thomas Bruederli wrote:
I like the old/current screen better because it brings a better separation of the different parts (headers, compose text, options). We already had
But my way it just looks the same as in message preview. The interface becomes more intuitive when unified. Why not make message compose looks the same as message preview?
feedback from a usability expert, that the gray arrow to expand the headers in the preview frame is not intuitive and I think we should therefore not copy that into the compose screen. And where can I now add CC, BCC and stuff?
Additional headers and options would be displayed when you click on this "not intuitive expander" ;) It's just me who thinks that current compose screen in Larry just looks ugly?
Improvement of the current compose screen could be:
- Add toolbar buttons for send/save/cancel and move the current form
buttons to the bottom of the screen. That's what we have in the classic skin and it respects the top-to-bottom flow one might have when composing a message.
In my opinion we don't need more buttons, but current buttons should be moved to the toolbar for sure.
Is community not interested in the discussion? I'm waiting for more opinions.
On Wednesday 05 September 2012 16:14:48 Thomas Bruederli wrote:
I like the old/current screen better because it brings a better separation of the different parts (headers, compose text, options).
I agree with Thomas here.
We already had feedback from a usability expert, that the gray arrow to expand the headers in the preview frame is not intuitive and I think we should therefore not copy that into the compose screen.
Maybe the usability export could also be consulted in this question?
And where can I now add CC, BCC and stuff?
Good question! I wouldn't like to see it hidden in some option expander.
Improvement of the current compose screen could be: ...
I agree with those as well!
Regards, Torsten
On 09/06/2012 12:26 PM, Torsten Grote wrote:
And where can I now add CC, BCC and stuff?
Good question! I wouldn't like to see it hidden in some option expander.
What a difference, link or expander. I see you need more screenshots ;), see http://alec.pl/larry. Keep in mind that these are only ideas, the look will be improved slightly + icons for toolbar.
We are totally agreed with larry skin. It is more usable, has significantly better look-n-feel. All of our enterprise customers upgraded to larry :-)
Nonetheless it works better on handheld devices.
Atti On Sep 7, 2012 2:50 PM, "A.L.E.C" alec@alec.pl wrote:
On 09/06/2012 12:26 PM, Torsten Grote wrote:
And where can I now add CC, BCC and stuff?
Good question! I wouldn't like to see it hidden in some option expander.
What a difference, link or expander. I see you need more screenshots ;), see http://alec.pl/larry. Keep in mind that these are only ideas, the look will be improved slightly + icons for toolbar.
-- Aleksander 'A.L.E.C' Machniak LAN Management System Developer [http://lms.org.pl] Roundcube Webmail Developer [http://roundcube.net]
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 09/07/2012 07:53 PM, Szuts Attila wrote:
We are totally agreed with larry skin. It is more usable, has significantly better look-n-feel. All of our enterprise customers upgraded to larry :-)
You wanted to say that larry doesn't need improvements or what?
On Fri, Sep 7, 2012 at 2:49 PM, A.L.E.C alec@alec.pl wrote:
On 09/06/2012 12:26 PM, Torsten Grote wrote:
And where can I now add CC, BCC and stuff?
Good question! I wouldn't like to see it hidden in some option expander.
What a difference, link or expander. I see you need more screenshots ;), see http://alec.pl/larry. Keep in mind that these are only ideas, the look will be improved slightly + icons for toolbar.
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.
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.
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. And there's no way to hide them anymore. 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.
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.
Best, Thomas
On 2012-09-09 20:30, Thomas Bruederli wrote:
On Fri, Sep 7, 2012 at 2:49 PM, A.L.E.C alec@alec.pl wrote:
On 09/06/2012 12:26 PM, Torsten Grote wrote:
And where can I now add CC, BCC and stuff?
Good question! I wouldn't like to see it hidden in some option expander.
What a difference, link or expander. I see you need more screenshots ;), see http://alec.pl/larry. Keep in mind that these are only ideas, the look will be improved slightly + icons for toolbar.
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.
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.
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. And there's no way to hide them anymore. 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.
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.
Best, Thomas
I have to agree with Thomas on this one. The current design is way clearer then the idea's proposed by Alec. It needs to be useful and clear for the simplest of users.
What i do would like to see is the buttons ( send, save and cancel ) also on the bottom, but that's my opinion ;-)
Cheers.
On 09-09-12 20:30, Thomas Bruederli wrote:
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.
I agree with Thomas. Users who want to add a CC or BCC should not be bothered with every possible header field. I mean, how many users do use Followup-To on a regular basis? I like the old design better.
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. And there's no way to hide them anymore. 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.
I figure that Reply-To can be an useful addition to the headers shown in the message preview; as users may reply directly from the message preview pane without opening the full message. When the Reply-to is displayed in the message preview pane, an user can already see that his reply will be sent to another e-mail address.
Cheers, Geert
The thing is that it is not logical to have the send, save as concept and cancel button on the right while all the other things are on the left.
One other thing is that the "logo" should be an home link, like it was.
Cheers!
Thomas Bruederli schreef op 09-09-2012 20:30:
On Fri, Sep 7, 2012 at 2:49 PM, A.L.E.C alec@alec.pl wrote:
On 09/06/2012 12:26 PM, Torsten Grote wrote:
And where can I
now add CC, BCC and stuff?
Good question! I wouldn't like to see it
hidden in some option expander.
What a difference, link or expander.
I see you need more screenshots ;), see http://alec.pl/larry [1]. Keep in mind that these are only ideas, the look will be improved slightly + icons for toolbar.
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.
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.
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. And there's no way to hide them
anymore. 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.
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.
Best, Thomas
Roundcube Development
discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev [2]
Links:
[1] http://alec.pl/larry [2] http://lists.roundcube.net/mailman/listinfo/dev
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.
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. In old skin when you use (show) all headers, the textarea field becomes too small. So, this and unification with the message preview was the main reason for the change.
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.
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.
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:
- 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.
Am 10.09.2012 08:44, schrieb A.L.E.C:
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.
It also more intuitive for the user. I want to add a Cc: very often and I immediately seen an option which allows me to do this.
We can add these links back and keep new design. No problem.
Yes, please. :-)
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?
In my option it's more confusing if I only want to add a Cc: and instead the screen changes completely and I see many new fields I don't need at all.
Because now we have a scroller, so displaying big area of headers
- options doesn't make the body textarea smaller.
The scroller is a good idea, but still, I have to use it (additional mouse movements, clicks) to see a bigger part of the text.
Manfred
On Mon, Sep 10, 2012 at 8:44 AM, A.L.E.C alec@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:
- 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
Thomas Bruederli wrote:
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.
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Comments?
Regards, Thomas
On Friday, October 19, 2012 at 4:32 PM, Thomas Bruederli wrote:
Thomas Bruederli wrote:
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.
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Comments?
Looks insanely sweet. Any idea if tinymce supports a slightly more modern look?
Otherwise – very, very cool!
Till
On 10/19/2012 04:32 PM, Thomas Bruederli wrote:
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Looks good. What I'd change is:
- Remove bottom buttons.
- Spacing between From, To, CC can be smaller
- Improve TinyMCE look
On 2012-10-19 11:56 AM, A.L.E.C wrote:
On 10/19/2012 04:32 PM, Thomas Bruederli wrote:
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Looks good. What I'd change is:
- Remove bottom buttons.
- Spacing between From, To, CC can be smaller
- Improve TinyMCE look
I like the look - just throwing in my 2c on something else.
For me, I think having the TabIndex of the Send button come after the Compose window is better than having the Attach button after it. So you can just go <tab><enter> and send an email immediately.
Cheers, Mark
(Not sure if it's been discussed already sorry - been AWOL from the list for a while.)
A.L.E.C wrote:
On 10/19/2012 04:32 PM, Thomas Bruederli wrote:
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Looks good. What I'd change is:
- Remove bottom buttons.
Yes, I wasn't sure about these buttons either. They support the top-to-bottom workflow and have also been around in the old skin. But I agree that they eat up some space and are actually duplicates of the toolbar buttons. What about hiding them on small screens?
- Spacing between From, To, CC can be smaller
Ack
- Improve TinyMCE look
That's probably another task which we can approach later.
~Thomas
On 10/22/2012 12:07 PM, Thomas Bruederli wrote:
Yes, I wasn't sure about these buttons either. They support the top-to-bottom workflow and have also been around in the old skin. But I agree that they eat up some space and are actually duplicates of the toolbar buttons. What about hiding them on small screens?
That's an option. However, it might be confusing for users.
A.L.E.C wrote:
On 10/19/2012 04:32 PM, Thomas Bruederli wrote:
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Looks good. What I'd change is: 3. Improve TinyMCE look
Maybe the cirkuitSkin would fit in here: http://www.cirkuit.net/projects/tinymce/cirkuitSkin/
But only for Larry and not necessarily for the classic skin...
~Thomas
Hi folks,
2012.10.24 19:21, Thomas Bruederli rašė:
A.L.E.C wrote:
On 10/19/2012 04:32 PM, Thomas Bruederli wrote:
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Looks good. What I'd change is: 3. Improve TinyMCE look
Maybe the cirkuitSkin would fit in here: http://www.cirkuit.net/projects/tinymce/cirkuitSkin/
But only for Larry and not necessarily for the classic skin...
and there I was wondering: do we actually NEED the ultra-powerful TinyMCE for simple email composition? Maybe something lighter would do just as well? For example, the standard zipped distribution of NicEdit (http://nicedit.com/) appears to be 50 times smaller than standard zipped distribution of TinyMCE. So again, do we really need all the bloat that TinyMCE has to offer?
Rimas
Hi Rimas,
On Wed, Oct 24, 2012 at 7:39 PM, Rimas Kudelis rq@akl.lt wrote:
and there I was wondering: do we actually NEED the ultra-powerful TinyMCE for simple email composition? Maybe something lighter would do just as well? For example, the standard zipped distribution of NicEdit (http://nicedit.com/) appears to be 50 times smaller than standard zipped distribution of TinyMCE. So again, do we really need all the bloat that TinyMCE has to offer?
You mean that TinyMCE actually is not so tiny...?
I would like to warn against replacing it with a different editor; the rich text editor is a pretty important component, and should be dependable, working in all browsers, and be coming from an active project. TInyMCE is a very active project, which will ensure continuity. Of course, it is not bug-free and it might be a little big, but changing to a different editor is risky and comes at a cost as well.
BTW Wordpress uses TinyMCE with a very minimal button set and monochrome buttons, if you're concerned about the looks and usability, it might be worth a look.
-- Mike
Looks good!
-- *Victor Benincasa* # *Mobile*: +55 (11) 992-227-227 | ID: 55*11*51775 | Skype: vbenincasa # *IT Manager* :: Networks, Applications, Systems, Security, Advanced Support
On Fri, Oct 19, 2012 at 11:32 AM, Thomas Bruederli roundcube@gmail.comwrote:
Thomas Bruederli wrote:
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.
Finally, here we go. This is my proposal how to improve the compose form with the things we already discussed here and how to align its look with the message view.
Comments?
Regards, Thomas
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Am 07.09.2012 14:49, schrieb A.L.E.C:
On 09/06/2012 12:26 PM,
Torsten Grote wrote:
And where can I now add CC, BCC and
stuff?
Good question! I wouldn't like to see it hidden in some option
expander.
What a difference, link or expander. I see you need more
screenshots ;),
see http://alec.pl/larry [1]. Keep in mind that these
are only ideas, the
look will be improved slightly + icons for
toolbar.
My opinion:
Message Display
I like the new version, because it make the display of the message more consistent with the display below the message list. And the expander arrow should already been known from there.
But I think it should be possible to display/hide the header source separately, you need it much less often and it confuses a lot of people who don't know what this is.
Compose Message
I would prefer if the Cc: and Bcc: fields could be activated separately, because the are used much more often than the other additional fields.
I also prefer the curent positon of the Send, Save, Cancel buttons, They are easier to find and make the screen more intuitive. And you do need them every time when you compose a message, so they are really important.
Manfred
Links:
Am 05.09.2012 16:14, schrieb Thomas Bruederli:
I like the
old/current screen better because it brings a better separation
of
the different parts (headers, compose text, options). We already had
feedback from a usability expert, that the gray arrow to expand the headers
in the preview frame is not intuitive and I think we should
therefore not
copy that into the compose screen.
Indeed it took me a while to figure out how to unhide the other fields, so it really seems to be not very intuitive, but now I find it very convinient.
In my opinion it should be used either on both screen or on none. Else the interface becomes even more confusing. On the current compose screen the plus sign is used to unhide fields instead of the gray arrow. Maybe this is clearer...
Manfred
-
A.L.E.C -
Barnabas BONA -
Geert Wirken -
Jan M. Dziewulski -
Justin van Beusekom -
Manfred Usselmann -
Mark Little -
Michiel Beijen -
Richard Pijnenburg -
Rimas Kudelis -
Szuts Attila -
Thomas Bruederli -
Thomas Bruederli -
till -
Torsten Grote -
Victor Benincasa