Thoughts on the Horizontal Workspace?

Beta
#1

Hi everyone,

I wanted to get your quick feedback when it comes to using the Horizontal Workspace. Definitely chime in with your own words, but here are some questions we had

  • Do you use the Horizontal Workspace as your primary workflow?
  • How often do you use it compared to vertical?
  • Are there scenarios when you find it more useful or advantageous?

So what am I getting at? Well, we’re considering discontinuing it. There are some things we want to explore from a workflow/usability perspective, and we keep coming back to limitations the Horizontal Workspace imposes. Without considerable amounts of time to account for contextual changes, we can’t reasonably approach the following two items.

  1. Adjustable workspace width. For example, making the Inspector wider.
  2. Splitting up the Workspace panes left/right. For example, Outline left and Inspector right. Or just having one of them floating independently.

I understand that a key use case for Horizontal mode is working with Headers (and perhaps Layouts) since you can see the full width. That being said, post responsive styling the preview is scalable. Clicking the desktop icon will scale the preview down to fit the available space while still depicting an accurate desktop view.

This discussion will help us gather some information to be better informed with how to prioritize the roadmap for the builder UI.

Thank you! Looking forward to your thoughts.

1 Like
#2

Just my two pennies worth (and not really worth more than 2 pennies :wink: )

I have not used horizontal workspaces since the Header and Footer builders used them exclusively. I’m sure they are a taste preference, but on a larger 27" widescreen there is a lot more horizontal space (for the vertical workspace). Even on a 14" macbook pro I don’t find the vertical workspaces a problem… it used to be a problem before being able to preview at different screen sizes.

I don’t pretend to speak for everyone, but for my experience I wouldn’t even notice if the horizontal workspace vanished.

2 Likes
#3

Ditto. Never use it.

1 Like
#4

I never used it either.

I think if users are used to the vertical version, then they mostly stick to it because the horizontal would requires a different workflow and most automated habits are broken.

I don’t think many would keep the horizontal one as the default because it is so high. On a 15 inch laptop, it covers two thirds of the viewport! It also affects the design. Page layout is deforming unnaturally in some cases. Plus it doesn’t scroll by the mouse scrollwheel, nor it can be dragged. I don’t see any other way other than using the bottom scrollbar.

I think if you discontinue it, hardly anyone will notice. :slight_smile:

2 Likes
#5

Same as the others, never used horizontal.

I find vertical follows the natural browser flow of creating content and user interaction, whereas, horizontal though possible feels clunky.

1 Like
#6

There are still horizontal work spaces?? :rofl:

Never use them either.

#7

Same here. I prefer the vertical workspace layout.

#8

I like this idea and the floating/docked inspector if done right as there is to much jumping around if you want to customise on one Div Then customise in the next you are clicking to get back and forth and losing your place this would be so much faster. 3 clicks become 1 click. can add up allot especially with these nested providers.

In the current state I agree the horizontal layout doesn’t really work.

Maybe this doesn’t work either but I have done a very quick mock up. of an idea I had a while back.

Here I have swapped the bars top 2 bars around as it makes more sense to have the bread crumb next to the big box. I think I have the wrong layout here as the breadcrumb should be left of the Column/ effects buttons.

I thought Icons next to the toggles could work to shrink the space and use alternating scheme just so you don’t get lost. Optional label could be rotated 90 in that slim space.

horizontal
horizontal1267×389 27.1 KB

Icons for margin, padding, border, radius - taken from old styling tool - stylizer used above
icons*
I can’t really back this idea much to be honest.

Last one as we are talking UI. (maybe this is other the top. please don’t shoot me.)
Would it work to remove anything optional not currently used from the inspector and add them like you do modifiers to an object. e.g. like blender.
image
Depending on how easy it is to add these this could be more enjoyable?
Populated via a dropdown grid? - label/icon. Just click each one you want to add.
Sometimes you might not want to remove them but toggle if they are active or not.

Just ideas anyway

#9

Thank you everyone! Really appreciate the feedback here. It’s a relief to know that none of you are heavily relying on it.

@scotbaston, with your main workflow being on a large screen it would be more helpful if you could see the Outline and Inspector simultaneously.

@Misho, you’re right, it’s fairly tall and makes visualizing your content difficult when so much of the screen is covered.

@strobley good point on it feeling more natural.

@samc, I’m really grateful for all the consideration here in what you’ve put together. Lots of great ideas and perspective. This is pretty much what I meant by having to take time to think through horizontal mode. It’s such a different paradigm and over the years we’ve spent quite a bit of time and energy maintaining it. What we’re realizing is that it’s limiting our creativity in other areas because of all the variables it brings in.

In regards to Blender modifiers, I absolutely love the model of having more or less having a blank slate, then you incrementally add things to it. This is an excellent choice UI pattern for isolated and composable things like Loopers, Masks, Effects since you don’t need them on every element. That said, I fear it doesn’t fit well alongside so many of our existing conventions. Each element is distinctly different.

I do think that’s on the right track if we wanted to explore some kind of “V3 element” system. We’re talking very hypothetical here and not anywhere close to what Cornerstone is capable of in its current form. But to your point, what if instead of adding a “Grid Element” you just added a blank “Element” and then added a “Grid” modifier to it? Everything would more/less be a single DOM node (HTML tag) and you’d build upon it adding your effects, backgrounds, etc. Then you could use that system to build up smaller patterns like buttons, headings, cards, accordions, etc. that get saved into your element library via the component builder. We’re definitely talking outside the box here, but it’s fun to explore and talk about these concepts.

2 Likes
#10

This could work well. At the very least you might define a type of element [text (h1…) / Container (div…)/ img /…] that has its set own set of base parameters. one being html tag to use. Hopefully from there you can keep everything quite modular. Then as you say save that into an element library.

Yes future possibilities sound great. I guess you can just keep this in mind when developing anything new. I’ve always had a great interest in UI. Even when at school we had these rubbish computers running BBC basic. I added a mouse UI interface with rollovers when everyone else was just keeping to “enter your selection 1-4”. Although the year below got visual basic the next year. sad times :frowning_face:

#11

This could work well. At the very least you might define a type of element [text (h1…) / Container (div…)/ img /…] that has its set own set of base parameters. one being html tag to use. Hopefully from there you can keep everything quite modular. Then as you say save that into an element library.

Right, so based on the tag you’d have some hard limitations. Like if you picked img you would have the controls to populate the actual src and alt attributes. If you chose a you’d get a link control. Because of the nature of HTML, those couldn’t be added iteratively. You could definitely turn an a tag into a grid though.

Yes future possibilities sound great. I guess you can just keep this in mind when developing anything new. I’ve always had a great interest in UI. Even when at school we had these rubbish computers running BBC basic. I added a mouse UI interface with rollovers when everyone else was just keeping to “enter your selection 1-4”. Although the year below got visual basic the next year. sad times

That’s awesome. It’s wild how much we can take for granted given the history of software. I get a similar feeling from a more recent example of talking to people who never had to account for the peculiarities and limitations of Internet Explorer. :smiley:

#12

It would keep the whole element system much looser overall.

Allow the possible functionality to apply a lets just call it a “modifier stack” ( component style (shared instance) or as a the usual Preset style(unique ) ).
So now the user would go to any element and apply that same stack of modifiers linked or not.

This could potentially reduce CSS as you might convert each modifier component into its own CSS class and reuse. Useful if you wanted to apply sitewide padding and adjust as necessary. or font style modifier. I’m sure the theme reboot is doing its own thing with regard to this.

You have CSS variables working which also works but this other way could be easier to setup. I can see this could be way down the line but hey worth considering the advantages you could get from making more modular.

You probably missed the worst days of web dev. Comparable to a horse with 4 broken legs and M$ were still forcing it out the door to race.

#13

I had a crack at using Horizontal workflow a while back… and lasted about 4 hours.

It (was) actually slightly frustrating having to use the Horizontal workflow for Headers and Footers (a few Pro iterations ago). I may have been able to change that back then, but stupidly probably didn’t realise… haha

Might be worthwhile running this by the Elite developers as well?

Cheers,
Sam

#14

No need for horizontal workspace for me too.

What would be really great (but most probably impossible): Having the workspace in a new window, that can be moved to a second screen, so the complete first screen can be used to preview the page.

… would feel a little more like photoshop :wink:

1 Like
#15

+1 for probably impossible floating external workspace

#16

Pretty sure this has been discussed previously and wasn’t possible/feasible. it would be nice though

#17

@samc, definitely lots of opportunity there. We’ve barely started exploring that yet, but I’d love to see a system that could create arbitrary styles (global or local) and reuse them in many places. I mean, it’s just CSS right? That’s pretty much how it was designed to work - we’re just presented with the challenge of a visual abstraction that makes sense.

You probably missed the worst days of web dev. Comparable to a horse with 4 broken legs and M$ were still forcing it out the door to race.

:rofl: Good times. IE9 was the first one I had to really make concessions for professionally.


@sam_futr and @ULinn thanks for chiming in as well!

What would be really great (but most probably impossible): Having the workspace in a new window, that can be moved to a second screen, so the complete first screen can be used to preview the page.

I had very rough proof of concept for this at one point that decoupled the live preview from the rest of the workspace. It’s theoretically possible, but there are lots of rough edges.

The biggest issue is that we can’t overcome how focusing browser windows works. Even if you could split the application into multiple browser windows, you’d need to click twice anytime you switch. The first click to focus that window, and the second to do whatever action you need. This would quickly get annoying since you probably don’t want to mentally track which window you clicked in most recently. This kind of technique is best suited for a native desktop app which is a significant commitment to make in many different ways.

3 Likes
#18

Yeah this makes total sense, and would also be super annoying haha…