Hi Richard, thanks for your feedback. Glad you like the changes in templating - I agree it's great to finally have proper areas, because they make some things (e.g. optional content) much easier to handle.
Am 14.02.2012 um 13:18 schrieb Unger, Richard: > Thanks for the 4.5 sneak-preview. Nice! > > My feedback would echo what has been sent so far: generally the concept of > the areas and the new look of the editor is very nice. The disappearing bars > are IMHO not a good solution (more on this below). The different > preview-types (smartphone, tablet - though not working yet) are a nice > addition. Some small bugs obviously need working out. > > The disappearing bars - I think this is bad for 3 reasons: > - first, it confuses the editors. Not seeing what they can edit right away > means they have to click everywhere to discover editable content, or once > they know the "page-bar-trick", they activate that, begging the question why > it wasn't activated in the first place. > - second, it makes editor's lives harder: whereas they used to be able to > open the dialogs with 1 click, now they need 2: activate the bars, then edit > the content. I therefore also oppose showing only the area-bars initially. > Show it all, save the editors some clicks! > - third, while it works well in the STK's rather "rectilinear" layout, > appearing and disappearing bars will be difficult to accommodate in other, > more "freeform" layouts. It will lead to the layout "jumping around" as the > bars are hidden and shown. Thus disappearing edit-controls will present > additional challenges to templaters working without the STK. I really think this is a matter of perspective. I don't think that the new editor confuses people more than the old one. On the contrary, actually. In our tests, users were a lot more confused by the amount of bars visible at any time on a page. They welcomed the changes introduced by the 4.5 editor, since it makes the structure and immediate neighborhood of the component, they wanted to work on, more apparent. That is especially true if you work with a page you don't know or if you work with Magnolia infrequently. Additional clicks are a burden, if they are useless. If they provide you with a better overview, I believe they're worth it. 4.5 requires a slightly different training of users, but we believe the story is a simpler one. - If you'd like to edit anything on the page, click on it. Then look for the closest edit bar. - If you'd like to add an element to an existing group of components, click on any such component. Then look for the closest placeholder. If you've ever watched a user trying to find the correct New bar in 4.4 in order to add a teaser at the end of a teaser group embedded in another group contained in the main content column, you'll now that the last point is a clear plus. Don't get me wrong: I get your point and I acknowledge that we're also loosing something (everything that is editable is visible *at once*), but we believe we gain more than we're loosing. Even at the cost of one additional click. Check out the next beta release due within a day or two. We've implemented a number of refinements, which will save editors, if not clicks, then at least unnecessary scrolls to the last position they edited at :-) > > > Generally speaking magnolia's page editor has to satisfy 2 requirements: > 1) to make as clear as possible to the editors what and how they can edit the > content on the page. > 2) to present the editors with a view of the web-page as close to what the > published version will look like as possible. > > > Finding a GUI that can meet both these goals is obviously a big challenge, as > the requirements are somewhat at odds with one another. So far magnolia has > used what I would call a "2 modes" paradigm: > - In "edit-mode", the bars were all visible, so the layout was somewhat > "deformed", but editing was easy: just click the edit button next to the > content you want to change. > - In "preview-mode", the bars all disappear, giving a view of the page that > is usually 100% like the published version. > > Our editors (we have >120 editors working with one magnolia system) have > found this very natural, the rate of questions about this part of > page-editing is pretty much zero. > > So personally, I would keep *all* the bars visible, and only hide them in > preview mode. (i.e. keep the current behavior). > > > > Some ideas about future directions for the page-editor to take: > > - Content Place-Holders should have the "correct shape" for the content being > created (see my screenshots for an example mock-up of what I mean). You can actually style placeholders yourself as template editor. The idea behind this is exactly what you're describing. > > - Rework the UI for including images and documents. Currently this is the > area that we receive (by far!) the most questions about. Editors have great > trouble with the concept that DMS-content has to be published separately, > they have great difficulty uploading and choosing images. Magnolia > desperately needs an "image-picker" - a thumbnail-view of DMS content. That is planned for 5.0. It's one of the core stories we're currently following. > > - Hovering could be an alternative for a new UI - if the edit-controls could > be realized in such a way that they take up no space in the layout (ie float > above the layout), a page-editor could be devised which shows these controls > on hover, allowing 1-click access to the dialogs (or to inline-edit > features). In this way you could integrate the "edit-mode" into the > "preview-mode", at the cost of having to move the mouse around a bit to > discover editable content (but at least you wouldn't have to click > everywhere!). As I said, you don't have to click everywhere currently, the story is you click on what you want to edit. Apart from that, I like your idea of floating controls - we've had that in our 5.0 sketches as well. We even had overlays working in 4.5 at one point, but we had our issues that were difficult to resolve. The problem is a bit that bars can overlap, if you have to show more than one. We could stack them, of course, but that would change the picture again and again. I'm not sure we'll ever merge "edit" and "preview", though. The split is useful also for other purposes, namely for proper version handling (you explicitly start editing a page by leaving its preview - that creates a new minor version of it). > > > In the meantime, thanks for all your effort and a great product! Thanks a lot for your time and your great feedback. Greetings to Vienna Andreas > > Regards from Vienna, > > Richard > > > > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] > Im Auftrag von Andreas Weder > Gesendet: Montag, 13. Februar 2012 18:21 > An: Magnolia Dev-List > Betreff: Re: [magnolia-dev] Re: Magnolia 4.5 sneak preview ! > > Hi Matt, > > thanks a lot for your feedback. You'll find my remarks below. > >> As you requested, here are my initial thoughts: >> >> 1. I have to admit, it took me a moment to figure out that I had to click on >> an area to get the edit bars to show up. Once I realized that, I really >> liked it. Something that may help, would be to add hover & focus states to >> the editable regions, both states could just add an outline property around >> the component. I think this might also help to distinguish between what >> regions are editable vs. those that aren't. For instance, the Table of >> Contents on the Large Article page isn't editable, hence, it wouldn't get >> the hover & focus states. > > What you experienced is also what our user tests have shown. One of the last > things we did before testing this snapshot and releasing it for you to > comment on, was to turn off area bars on the top-level. The tests have now > shown that this change was too aggressive. Our users felt somewhat lost > having to edit a page without any bars at all. And, clearly, we do not want > that editors have to click on every visible component in order to find out > what is editable and what not. > > What we plan to implement 4.5 is: > - to show top-level area bars if you enter a page. > - maintain both the position and the selection state of components during > page reloads. > > The latter should properly bring you back to where you where when you started > your last edit and right before the page reload. > > The reason why I do not want to introduce hover states currently is two-fold. > For once, I believe they won't solve the problem: you still have to move the > mouse over the entire page to detect what's editable or not. I prefer to have > a clear "call to action", so to say, in the form of a visible bar. In fact, > that's also what some users have suggested. > > Second, hover is new and not connected to the existing way of editing. We've > already introduced a number of visual changes and if it is not absolutely > necessary, I'd like to avoid introducing another element to the set. > > 4.5 is supposed to be an important step towards Magnolia 5, while still > remaining true to what users know from the 4.4 family. We tried to clear-up > the fog of bars and rework templating, readying it for the future. Magnolia > 5, on the other hand, has the goal to make things more tangible in general. > The main and mostly only focus of Magnolia 5 is the UI. We'd like to deliver > a more direct interaction with your content and with the tools allowing you > to work with it. Intuitively, to me, hover belongs to Magnolia 5, if we'll > ever introduce it at all. > > >> 2. I really like the 'New Component' placeholder. One thing I'd suggest >> would be to make the entire 'New Component' placeholder clickable, instead >> of just the 'Add' button. > > Absolutely. Every user in our tests (double-)clicked on the placeholder. > We'll add that. > > >> 3. The '+' to add another tab item to the Tabbed Teaser component may >> be easily missed. Not sure I have a recommendation for this. For >> reference, see the Tabbed Teaser component at the bottom of >> /demo-project/multimedia.html 4. I really like the other placeholder >> areas :) > > Great. Placeholders, btw, are automatically injected, but you can also > provide your own HTML/CSS to style them. So, theoretically, we could use only > the "+" tab here (and no contained component placeholder) to add a new tab. > Likewise, in the carousel on the home page, we could supply a (+) button next > to the numbers for switching panels, allowing you to add a new teaser > directly. > > However, if I remember correctly, the problem we currently have here is that > the tabs are generated using JS. We thus will have to also add a way to > programmatically add a placeholder as well - and I'm not sure if that will > make it into the final release. I'll have to double-check this last point > with Philipp, however. > >> 5. I really like that the title of each component is shown in the edit >> bars (i.e. Internal Page Teaser) > > Glad to hear you like them. We've aligned all labels on all bars on the left, > so that you can skim them quickly from top to bottom. The buttons are all on > the right, with the more destructive "delete" operation slightly set off from > the others. The current plan calls for the removal of all buttons from the > bars in Magnolia 5 and to make the bars more interactive (e.g. you just drag > and drop the bar to move a component). > >> >> Ok, that's what I have for now, I'll try to add some more to this list >> as I work with it more. I think content authors are really going to >> like these changes! Thanks for the awesome work! :) > > Thanks a lot, Matt, and keep your suggestions and feedback coming. We really > appreciate it. > > Cheers, > Andreas > >> >> Cheers, >> Matt >> >> -- >> Context is everything: >> http://forum.magnolia-cms.com/forum/thread.html?threadId=939ca472-a01f >> -4178-a619-0b25aa5c3647 >> >> >> ---------------------------------------------------------------- >> For list details, see: >> http://www.magnolia-cms.com/community/mailing-lists.html >> Alternatively, use our forums: http://forum.magnolia-cms.com/ To >> unsubscribe, E-mail to: <[email protected]> >> ---------------------------------------------------------------- > > > > ---------------------------------------------------------------- > For list details, see: > http://www.magnolia-cms.com/community/mailing-lists.html > Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, > E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > > > ---------------------------------------------------------------- > For list details, see: > http://www.magnolia-cms.com/community/mailing-lists.html > Alternatively, use our forums: http://forum.magnolia-cms.com/ > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > <easier_to_understand.png><hard_to_understand.png> ---------------------------------------------------------------- For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
