mail UI feedback

[sonicthoughts]

Please see this document with screenshots: https://docs.google.com/document/d/1Y90B6ATAY5Df7b_2eRiQE6oj_RlaDboJ2bm67OPI8KI/edit?usp=sharing

WYSIWYG editor menu is obscured by civicrm menu when enlarged (this is necessary as there is not much space to edit a mailing.) and therefore you can't restore/save (css fix suggested, but probably needs some JS)

There are 2 workflows- Define Mailing has a sub-workflow of Attachments, Header, etc. but clicking Next button skips sub-workflow.  Screenshots included.

Other clarification around archived mail and image management.
It could be clearer how mail archives are made publicly available.  There are access permissions, references to Archives in the documentation.  Is there a built-in access endpoint or is it necessary to use one of these methods?: 

http://wiki.civicrm.org/confluence/display/CRMDOC/Using+Drupal+Mailhandler+to+Archive+CiviMail
https://civicrm.org/extensions/public-mailings-archive-3

Finally, Is there a method to improve WYSIWYG image handling?  Images are critical for email usage.  Ckeditor or Drupal integration have many enhancements but it is not clear how / where to integrate.  Also KCeditor integration would be a great default.

[Coleman Watts]

The wysiwyg problem is a pain, it's so difficult to get overlay-type things to stack nicely when they all want to be on top.
I'll bet the problem is worse in Joomla where the Civi menubar is in the middle of the screen and not the very top

For the 2nd point. The tabs aren't really intended to be wizard-like. They all contain sensible defaults and the assumption was that you'd only access them if you needed to.

[sonicthoughts]

I get it as far as the intended workflow, but is it possible to be a bit more consistent.  For example, the event and contribution page wizards first let you save a named entity and then modify it.  Perhaps I'm splitting hairs, but the Next button seems in consistent.

Event:
 http://screencast.com/t/PkyTpTJLso3J
http://screencast.com/t/TqQn7v45EJa
http://screencast.com/t/7jGxdFkZB

Mailing:
http://screencast.com/t/ouW4CBn3PE

[Coleman Watts]

Looks like Tim has a fix.
See https://issues.civicrm.org/jira/browse/CRM-16140

[totten]

The CSS patch works for me. It's lot easier than trying to manage the various z-indexes. Filed issue and PR: https://issues.civicrm.org/jira/browse/CRM-16140

Agree the tabs in "New Mailing" work differently than the tabs in "Manage Event". IMHO, that's (mostly) a good thing. The visual language in "Manage Event" originated in a world where Javascript was often unavailable or very slow. It imposes a requirement where you *must* save each tab separately. In the case where a user explores the UI (clicking various tabs, tweaking a few arbitrary fields), this adds several extra clicks and roundtrips. By contrast, "New Mailing" allows you to freely switch sections and requires less saving.

If you haven't already, check the "Layout" discussion in https://civicrm.org/blogs/totten/civimail-ui-refresh-v46 . It has a table with links to a few different layouts.

The layout which you currently see (by default) is very much a compromise. You might like one of the others better. I agree that the biggest problem with the compromise layout is having two levels of navigation ("Define Mailing => Review and Schedule" vs Mailing/Attachments/Header and Footer/etc). A couple ideas floating around:

 * Change the default to the 3-step wizard ("Content => Options => Review").
 * Keep the 2-step as default, but hide its top-most navbar. There's no need to think about that navbar while writing.

[sonicthoughts]

I guess I'm late to the party .  thx.

[totten]

Your feedback is definitely appreciated, esp. considering that we still have some open questions (like whether to switch from 2-step to 3-step or to hide topmost navbar).

Re: images - We're trying to walk a tricky line here. On one hand, it's simpler for Civi if it implement one WYSIWYG integration (i.e. we only have to do it once; there's less testing; there's a richer API). On the other hand, the image-handling is a bit more than we want to take responsibility for, and it would be nice to reuse those bits from the CMSs; unfortunately, the only way to re-use the image-handling is to get involved with some fairly abstract, server-side, CMS-specific APIs (which are harder to work with).  Not a solution... just describing the context...