UI/UX Suggestions

[markadrake]

I apologize, didn't know whether I should mark this as a bug, a feature, etc. I just want to share some thoughts and I hope that you find the feedback useful.

Earlier this week my team and I were at a proverbial fork in the road. We either needed to commit to the grid layout, and using grid editors entirely - or move to an alternative. We started evaluating Stacked Content's approach and it was unanimous across the team - Stacked Content is the way to go. It fits our design process, reduces complexity for the end user and developers, and is future-proof when we begin using CSS Grid Layouts too. Great.

But I'd like to share my experience and offer some feedback - in which I'm more than happy to help fix / submit a PR / etc as soon as I read your feedback.

1. Why did the UI / UX change from one state to the next?

At its initial state, Stacked Content provides a clear and obvious beacon to getting started.

But later takes it away.

I'd argue it's worth leaving the UI / UX the same, even when content has been already added to the page. So you have 1 box at the top, and 1 box at the bottom. No big deal but I'm a stickler for consistency. You introduced me to some iconography - and I just learned that it means "add content". Now after adding some content - it's completely disappeared. Where did it go? I try to avoid moments of confusion like that.

2. Maybe 10px is too small a target - even for desktops with pointers.

Okay, so the solution you went with afterwards isn't bad. It cleans up the visible real estate. I understand why you did it. But I still have some gripes.

Earlier I talked about the icon I learned from the first step. Well it's not repeated here. Can we make them consistent? I'd vote the plus icon, but I don't have a strong opinion on the matter.

The real thing that I feel is broken is the 10px window of opportunity you have to reveal the + icon.

For a while our team didn't even realize there was a + icon towards the top. We kept using the one at the bottom, and having trouble either activating the hover or keeping it hovered.

Would it be too much to ask if we left the + icons visible at all times? It provides a better experience on desktop, providing a larger target area to hit with your pointer, and it's clear and obvious like before! , *Also this is more mobile-friendly.

I get it, who the hell uses the backoffice on a mobile device? I don't, my clients haven't asked, why care? Well I care deeply about it because mobile device usage is only going up, and the way we use our mobile devices is changing constantly. I think it's important to follow some HUIG at all times when developing for the web - even if it's not your focus. Pick one - Apple, Google, or another and follow their best practices for mobile interaction.

3. Can we rearrange blocks of content?

The last thing we asked ourselves was "hey can we move content around"? It wasn't abundantly clear if we could or not, and where it was safe to click and drag. Was there an edge we could highlight? Was it safe to click and drag over my text or would that engage the editor window? We just weren't sure, until we tried it, and it magically worked.

I could land on either side of this debate, but wanted to suggest making it clear and obvious that you can indeed reorder these stacks of content, and giving a clear handle to do so.

The icon I picked is not necessarily the one I'd use, I just had to pick one for illustration purposes.

4. Please don't use an anchor tag in this way.

So the last step we needed to take was adding our front-end styles to the backoffice, scoped so they don't interfere with the UI of Umbraco. We solved this once for grid layout, and it was super easy to do for Stacked Content too.

Well, mostly.

See you use an <a> tag to wrap the rendered HTML output of a piece of content. Besides that being malformed and incorrect it also makes it slightly tougher to get the appropriate styling, since everything is adopting my anchor tag styles.

I've never been a fan of angular, but I dabble in it because I have to because that's what the Umbraco Core team chose. I believe that this line of code may be the culprit.

What little experience I have with angular - is there any conscious reason why you decided to wrap rendered HTML content in an <a> tag that I don't know about? The click handler should work on any element - so could we replace this with a <div> or <section>?

I know I'm terribly untactful and apologize if I come across that way. I think you guys have done a great job and appreciate that you released this to the public - for free. I feel this is the right way for content authors to build their pages. It's much more friendly up front making no decisions on your behalf of what front-end framework you use, and it's future proof for when CSS Grid Layout is more widely available. Thank you again for a great Umbraco package.

[markadrake]

Regarding My Number 4

Further discussion happening on Twitter, James brought up a very valid accessibility concern that if we do change to a <div> with the click event handler, we may lose keyboard support.

Again, I don't have a ton of experience with SPA frameworks. I create some property editors, that's about it. In and out.

Replacing the <a> with a <button> does nothing for us in this case - as it would still be malformed and still present CSS styling issues.

Perhaps it's not a terrible idea to use the toolbar on the right and put an edit icon above the delete icon? That's my "I gave it 10 seconds" suggestion. I'll continue thinking about it.

Maybe I'll finally carve some time out to formally learn how to perform manual tests for accessibility.

[mattbrailsford]

Hey @markadrake thanks for the feedback. It's great you took the time to review Stacked Content and really glad you are your team are keen to role with it.

In response to you questions then:

1/2 The initial hit element was based on similar design elements at the time, though I'll admit, things have changed a little since then (we did base it on the grids styles). Personally, one of my gripes with the grid I had was the amount of "chrome" it added to the UI and so our aim was to minimize this so that it was just the content and the UI came into view contextually.

Regarding the '+' hit area, yes it is a little small, but it does actually expand when you roll over it, so the roll out is a bigger area. I'm not averse to having the '+' icons constantly visible, but it could get a little distracting. You actually get a '+' icon between each stacked item as well so you can insert content between other content items. Maybe we have them visible on initial load, then when you rollover, they fade out suggesting they are there, but you gotta roll over them? We could on mobile have them there constantly.

3 Regarding the drag handle, again I'm not averse to an explicit handle in the call out on the rhs. I'd still want to be able to drag and drop via the main content blocks though like we currently do, but I can see how an explicit handle could help.

4 No explicit reason for this so happy to change. I probably built it as a wireframe based thing initially, but then we added previews and I didn't think on to change it. I don't really want to go with the edit button option though as I think most peoples inclination will be to click the thing to edit it.

FYI though, I'm not really a fan of people trying to do true WYWIG previews. I'd always suggest to make it somewhat wireframe like as a) it helps the editor focus on the content, not the fact it's not 100% like the design and b) simplifies your previews and helps prevent confusion (as in your example screenshot, what should we expect the button in your previews to do?)

I think that's a good starter for 10.

Again, thanks for the feedback.

Matt

[markadrake]

Thanks Matt,

I'm glad my feedback was constructive, I have to pay more attention to that than I'd like because I'm usually cut-and-dry. I really appreciate the work you put in.

Also if there is something I can do to help or support the project, I'm always looking to get my hands dirty somewhere. I don't do a lot of public contributions, it would be good for me to start interacting more with public repos and how others handle PRs and testing and such. Really looking to expand out of my comfort zone.

So more about 4, our approach right now has been to render the content block, the elements, the components as closely as possible to the front-end, without worrying about any of the specific UI elements.

For example - we have a carousel you can drop in.

• That carousel is going to render as expected - but the content author only has the first slide as we don't initiate the thing.
• The pagination links and arrows are where they are supposed to be, but they too aren't going to work.

We do that because some times a component, like our carousel, can have themes to them that is part of the content editing experience. You may want pagination in a circle format, or pagination as a thumbnail format.

Or when looking at the example above - there is a light, dark, and accent theme to each content block (for specific reasons).

We draw a line at interactivity.

I hope it's been constructive! Great Umbraco package Matt and Lee!

[mattbrailsford]

I get what you mean, but I guess I'd still leave out the theming in the preview. To me, if it's about style, layout, etc then you run the page preview. The content editor is there to represent your content "structure". In your examples I guess I'd render out some blocky "representations" of the visual elements, rather than the visual elements themselves. That way the editor can see what mode it's in, but to see what it really looks like, they've have to preview the page.

…

On 8 Dec 2017 3:22 pm, "Mark Drake" ***@***.***> wrote: Thanks Matt, I'm glad my feedback was constructive, I have to pay more attention to that than I'd like because I'm usually cut-and-dry. I really appreciate the work you put in. Also if there is something I can do to help or support the project, I'm always looking to get my hands dirty somewhere. I don't do a lot of public contributions, it would be good for me to start interacting more with public repos and how others handle PRs and testing and such. Really looking to expand out of my comfort zone. So more about *4*, our approach right now has been to render the content block, the elements, the components as closely as possible to the front-end, without worrying about any of the specific UI elements. For example - we have a carousel you can drop in. - That carousel is going to render as expected - but the content author only has the first slide as we don't initiate the thing. - The pagination links and arrows are where they are supposed to be, but they too aren't going to work. We do that because some times a component, like our carousel, can have themes to them that is part of the content editing experience. You may want pagination in a circle format, or pagination as a thumbnail format. Or when looking at the example above - there is a light, dark, and accent theme to each content block (for specific reasons). We draw a line at interactivity. I hope it's been constructive! Great Umbraco package Matt and Lee! — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgLyZI2rRxM4h6g9wnkBO7NMcs4vfo_ks5s-VQlgaJpZM4Q7LsC> .

[NikRimington]

Hi guys, Just came across this discussion and I had an idea regarding the +'s as I've had editors say it can be frustrating to find them. What if they faded out, not completely but enough to be visible but not a distraction? Then when you roll over them they come back to full opacity?

It could work even with a stack full of lots of content as they wouldn't be fully visible.

[leekelleher]

@mattbrailsford Let's discuss what to do with the suggestions on this ticket.
Feels like there's quite a lot going on here, which could be separated out to their own tickets/discussions.

[markadrake]

Thanks for being responsive and open to these suggestions. I don't really contribute all that much publicly - sometimes I'm to blame and sometimes maintainers just aren't as good as you @leekelleher and @mattbrailsford.

I can tell you from our experience that the UI of stacked content (such as the + button) has best served our content authors by keeping them visible, as well as removing a change on hover that impacted the height of the button itself.

A change in the height of the button may not seem like a big deal, but it had an odd effect if your cursor landed on just the right spot. And it causes repaint of everything in the DOM.

Thanks again, this has been an overwhelmingly positive experience.