Problems solved: Much easier move + copy to other pages. Improved orientation within the project. It is not imediately evident that the Label in the black header outputs the current page-name.
Yeah, but you got what I mean. My impression is that users will either use WS to craft rather small, very refined sites, or large ones, where pages turn to templates. In both cases, a combined display, as suggested could work.
You would delete the standalone pages panel entirely or just add a pages section to the navigator for quick view?
The thing is figma/penpot isn'g having folders and page/foder settings
we have way more than they do
I could probably squeze these in still but i feel like it would be a lil cramped for a comforatble use
Not sure deleting is a great idea
but I do agree that it would be handy to see them under navigator
Many apps give you hotkeys / icons to expand subpanels to full hight. This would result in what the Pages panel does today. The non-active panel is minimized to the bottom while the active one is enlarged.
Enlarging would also solve Folder problem.
I find improved orientation within the project a strong pro argument. Copy to another page (possibly simply by dragging from canvas, or navigator – while holding Alt) would be quite attractive.
Mentioned prototyping tools also manage frames (several boards within a page) in this setup. So WS has Folders, Figma and Penpots have boards.
Agree, there is potential here
actually pages as standalone thing can still remain when clicking in the top bar
just without an extra icon in the tabs
So this way with a shortcut we can open a full pages panel, which would be equivalent to clicking in the top bar, so we don't need to fiddle around with resizing and enlarging in the navigator
these resizing options are often handy but in the end its fiddling around back and forth
maybe resizing is useful to some, idk, but something that works great without the need to resize is better
I would make these vertically stacked sub-panels resizable. Some projects have relatively many pages, others have many page elements. Just by dragging the border between pages / folders and navigator would give you a sane default for the project.
So then the memorization of the resize position would need to happen on per-project basis
I feel like our first version of this should be fixed, would work great for 10-20 pages which is the majority
5-6 items would be visible all the time, then quick scroll
One could definedly start this way.
we prob need to do something about the pages button in the top bar, so its clear those are buttons
right now you realize they are buttons only if yo hover or tab
even though its consistent with the rest of them
I wonder if we could do something relatively small to make this more clear
don't really want to clutter the top bar with full button shapes
I know, that goes against your grain, but personally I would just remove the secondary printout of the active Page in the Header. It is quite unconventional and therefore not easy to buttonify. If there's a neat way to enlarge the pages-panel, I see no more need for duplication. I see no need for an actual standalone pages-panel if the enlarged version exists.
its needed for quick access to switching pages when in preview
but now that we have a quick view only in the pages, I would say this becomes even more important in the top bar to open full view
its kinda like the url bar in the browser on the top, especially if you think about dynamic pages
I think this could just use some love to become more clear and nicer
I would say this becomes even more important in the top bar to open full view
In what way would the standalone view differ from a fully extended pages panel? I imagine to look and work identically. I see your point with preview – but there could be other GUI implementions, too.
We could be showing it in preview only though
so this way its not taking space all the time
only in the way that its fully open in a large panel with just one click
only in the way that its fully open in a large panel with just one click
Hehe, but that's what I had in mind with maximizing.
Technically these merged panels would remain two separate GUI elements, they would just share one container. Both the Pages-subpanel and the Navigator subpanel had an option to consume the full container / all screen space in Y.
The attached is a super rough schematic sketch.
It would not solve the preview navigation, though.
I mean if you are in preview and you want to open pages in a large view with one click
This is how Photoshop does things. Clicking the sub-panel Label minimizes the active subpanel and gives room for the other panel. Another approach with the same effect.
A presentation navigation similar to Figma's is likely more familar – but without fast jump to pages, this would likely be tedious for larger projects.
yes we do that with the sectio header on css preview section
In preview you don't have access to navigator
Penpot does this in a powerful way. In preview mode you by default only have a typical Lightbox navigation. But you can quickly access both pages and boards.
Yes that's just a 2 dropdowns, the idea here was to reuse pages panel when accesed over top bar
Its essentially similar, though we assume a much more complex scenario: more pages, more actions, search etc
Navigator access in preview is not desired, preview is as close as possible to production, so won't have outlines etc
In other words, I think we need a full size pages panel easily accesible from the top bar in 1 click for preview
I also think its benefitial to have that during the build even with quick view in navigator, but not as necessary ... so idk
At some point you can't have all panels always open and always large enough to be readable, so you end up closing-opening them anyways
Maybe this would be a better deal if we move css preview somewhere else, so that there is more space
Advanced CSS panel in the style panel might acctually fully replace css preview panel in the future
and I aven think the Advanced CSS panel could be sticky - always open
Maybe this would be a better deal if we move css preview somewhere else, so that there is more space
Sounds like a good idea to me – but I see no good space in your current window setup. Using a broader standalone window likely would be nice. One could move it to another screen or side by side with the main window on large screens (similar to inspector) – but you then likely had problems aranging the windows upon re-opening projects.
Oh I didn't mean it as a floating panel
I mean what we have right now for pages holds true imho.
What we are discussing is how to make always visible access more handy, without the need to open standalone pages in build mode
in preivew mode we still need the same full-size pages view
We need to clearly communicate when we talk about preview and build mode, they are quite different
In my last post I referred to the CSS preview pane in Build Mode. Removing it from the bottom of the navigator would free space, as you mentioned. Making the CSS window (also advanced panel) broader would improve readability, as line breaks were avoided. As a beginner find the small width very crowded. I thought of a standalone window, as this might be relatively little effort, compared to possibly using more than one panel on each side.
standalone window is problematic, because you would find it constantly covering the canvas and moving it around
but more width in the right sidebar could solve this
maybe a floating panel as an option would solve this too, idk, but feels like the thing there needs to just work better instead of having 2 options for the same thing where one doesn't work very well
OK, I had in mind that resizing the Style panel would be out of discussion...
resizing is, but making it fixed wider - maybe
resizing on itself isn't a problem, but making all visual controls resize nicely is quite difficult
if we resize, we would have to let some controls stay the same
inputs are easily resizable but not so much toggle groups, spacing and others
space distribution might become weird too
but if everything is made generally wider and properly aligned for a wider sidebar - then yeah, its possible
if 20px of width would solve the entire problem - why not
maybe its not gonna. solve it though, so then this effort would be wasted
I doubt that 20px wider would be worth the effort. There would still be truncated property names and linebreaks in css.
@external window for CSS preview: Could you not use the drawer Chrome uses for docked DevTools? Or the Chrome sidebar that extensions may use?
The screenshot shows my bookmark manager using the sidebar.
You mean using browser extensions to show the UI?
Anything that would require additional extension to install is basically lost on 90% of users, so would't be my first choice by a long way
First and foremost I meant using resizable and dockable GUI that you don't need to maintain. Devtools was even designed to preview code...
thats a whole different topic
our advanced editor is not a simple reimplementation of dev tools css panel
lots of technical things I would need to write to explain it
in short - dev tools are great, but what we do is different
I can't judge the technical implications. What I see is rigid GUI constraints inside WS and relative liberty in Google's subwindows. I just wanted to drop this idea.
yeah, this is intentional and very important
we might be able to get the properties shown as shorthands in the future, but generally we constraint that thing to the model of CSS that webstudio supports and we synchronize everything across the visual designer and canvas
so its not just a random css editor, that would be 5 min of work
the challenge is to be able to have a great view on advanced section while also have acccess to the visual section
dialog/panel is easy to do, but it covers the canvas, so its always in the way
an additional panel on the left that would push away canvas/ not cover it could be an option but it will take away a lot of horizontal space, so prob not for everyone
The experience will vary a lot, depending on device. You could have such a second docked window open at all time on a 27 inch screen, but certainly not on a 15 inch laptop.
yeah, many are even on 13
in VR/AR this would be a big topic, as you can have as much space as you want and having each panel standalone draggable wouuld be huge
in a few years from now I bet we are going to design/build in vr
Check Oleg, this is what I mean. This is from a different builder I sometimes use.
