Some ideas for adding functions to Stacks

Hi, I’ve been using RW with only Stacks for years … and I was wondering if there would be any improvements to imagine to further improve the workflow. Here are some tracks: what do you think? …

Here is the basic interface of the latest version of Stacks (3.6.6). It’s very sober and functional (!):

Here, a Stack is selected:

Here is what I imagined. The Stacks could be colorized and named by the user so that he can better organize his work and avoid having to unfold the Stacks to see their content:

And by selecting a Stack, we could see this interface with additional functions:

Here are the details of the functions:

And here is finally a second proposal:

… and the details of the (identical) functions:

10 Likes

Ahh @isaiah will have fun with that. These are some good thoughts…

I agree…looks good…@isaiah will love and hate it…ehhehhe
Great work @isaiah

Oh, this is fun! Thanks for all the hard work. I know how much time this stuff can take. I really appreciate you putting so much effort in.

Even if I don’t use some of this – I still love that you were thinking about this stuff and I take every bit of this in consideration. In other words, this info will absolutely become part of future designs – but probably mixed together with a dozen other great ideas in non-obvious ways.

One thing I should probably point out: building user interfaces in native MacOS apps is non-trivial. Even in a UI like this that is largely composed of CSS, it can still take months of work to align the native components with the non-native web-based components.

Most of the UI work for Stacks was completed over six months ago. I’ve still been refining some toolbars and button colors, especially for dark mode – but changes as dramatic as you’ve proposed would definitely take months – so I’ll probably just have to file these suggestions away for the next big UI overhaul in Stacks 5. But… you never know… sometimes I can sneak one or two things.

OK, feedback. Here’s what I love:

  1. I love the titlebar that has both the name of the type of stack it is and a custom name. I love this especially since I added this feature last night. :stuck_out_tongue_closed_eyes:
  2. I love that you tried to keep it real and used a titlebar height that’s very close to the real height (you’re about 2px larger). Because that titlebar spacing has to be left in the layout even when the titlebar is not visible, that means every pixel there multiplies by each stack in the design.
  3. I love the second version with the long capsule shaped icon groups. That’s a cool design and something I haven’t personally tried. I have done extensive user testing on designs very much like the first one (with many little circles) – more on the at the end.
  4. I like that you have “Fold” and “Unfold” and “Enable” (I assume enable publishing). I currently use “hide” instead of “fold” – but oh man, I really like “Fold” – that makes so much more sense. And that’s something I can probably incorporate even in Stacks 4. I think I’m going to give it a try.
  5. I love the user-defined colors. I wish you had shown that one too me 12 months ago. :stuck_out_tongue_closed_eyes: I have another bit of UI that’s allows very similar color customization in Stacks 4 and uses the standard Mojave system colors as the basis. It works really nicely and it would totally makes sense to add this to the stack outlines. But that level of customization – along with a complete second set of colors for dark mode – and matching colors to both native and CSS. Yeah… that’s gonna be a bit of work. Months, definitely. I’m tired just thinking about it. LOL But consider that one on my short list. I’m kicking myself for not thinking of it.
  6. I really like using an arrow as the fold icon. I had always used the eye, but I think the arrow makes more sense. This seems akin to the way I use the an arrow (or chevron) for showing and hiding the library info pane at the bottom of the Stacks library.

OK, some critiques:

  1. Your title and info bar are a tiny bit larger than Stacks currently uses. You would not believe how much work I put in to keeping this thing as slim as possible. Every pixel that gets eaten up by the titlebar gets multiplied by every stack in the layout – and means a ton less space for users to see their content. So… 28px is the max – with at least 1px of top and bottom padding. 11px System font, for now San Francisco. I’d actually love to get that to 26px. But I think it would require all Macs to have retina displays.
  2. The titlebar width creates a new and difficult design problem. Some stacks are very very narrow. And all of the critical functions of a stack must be operational, no matter the size of the stack. With six buttons on the titlebar this becomes very very difficult. Other interesting accommodations have to be made for these functions when the stack gets very narrow. Unfortunately for some designs that have many narrow columns this may be the dominant mode of operation – so it can’t be too terribly cumbersome either (in other words – shoving everything into a hamburger dropdown menu is probably out of the question).
    To be fair, this is not really a critique on this design you’ve presented – it’s merely saying that doing things this way would create a new problem to solve.
  3. Italics have recently taken on the meaning of showing a file without changes. This is taken from old-school unix text editing apps, but has recently been picked up by some of the larger and more mainstream apps like VS Code. I think I’ll probably avoid using italic text in title areas unless it has a similar meaning.
  4. Although I love the capsule design, putting the close “X” in a capsule is probably not a good ideal. The X in a corner, especially in a black or gray circle is a strong idiom and one that Stacks has used since day 1.
  5. Placing the X away from other controls is very important. It’s a destructive action so doing all we can to help the user avoid accidental clicks is a good thing.
  6. The edit pencil. For years Stacks has had an “edit” button of some sort. But I think it’s rarely used. I accidentally unhooked the edit button in a build about a year ago – and I didn’t get a single support email about it. :astonished: I’m at least going into the Stacks 4 beta with the edit button entirely removed – you just have to double click a stack to edit it. :crossed_fingers:Removing any UI doesn’t always work out – wish me luck. I think this one has a good shot, but I have a backup plan if people hate it.
  7. The title edit button. I kind of think this one might be better as a setting in the info panel or directly clicking on the title. Stacks 4 will put it in the info panel. Mostly because direct manipulation would mean a second click on the titlebar – which already has the meaning of editing the content. I’d rather not over-laden the gestures with too many things if I can help it. I also think there’s room for adding other user-customizations (like color – but even more stuff) that might be challenging to squeeze onto the titlebar.

lastly, and this is the big one…

All of my original designs for Stacks 3 looked almost exactly like your first proposal (with circular buttons). And it wasn’t merely design. I spent months implementing it and preening the details as well. I went all the way through creating the real UI and sending it out to testers. I’m afraid the results were not very good. And that’s putting it mildly. In fact they were so bad that I had to trash the whole idea, delay the project 3 months, and start again building out different toolbar ideas.

The issue is small unlabeled buttons. Even with tooltips, even with a first-launch “this is how it all works” screen – people could not remember what the buttons were for and could not figure out how to do some of the basics and nearly everyone accused me of removing features which were right there. And this was with people who had used Stacks for years and were familiar with the basic functionality. It was far worse with new users and novices. They just couldn’t figure out how to use Stacks at all.

To be honest, I was totally crushed. It seemed like such a great design. It looked amazing. It created all kinds of new opportunities for directly manipulating each stack. And it eliminated so many toolbar buttons, and placed so many things exactly where the user needed them. But alas – no matter what I tried, most of the buttons were just too foreign and people could not figure them out. I had to change course.

To be honest, I debated telling you this at all. I know how finding this info out made me feel and it was not good. I tried so hard to force this design on users in a bunch of different ways. I really wanted to make it work. Not to mention that I had no backup plan – and it meant a huge redesign task and delaying the project. And I was frustrated, sad, and disheartened when I couldn’t make it work. And maybe, being a bit honest for a minute, I might have been a bit disappointed in users – I wanted them to love this – I wanted them to try harder to get it – but I just couldn’t make it happen. For me this was crushing – and I really hope that you don’t feel that way hearing this too. :frowning:

10 Likes

Arrows like this, to me, would suggest that it would move the stack down (i.e. below the stack immediately below it). Which of course would be a nice feature in itself :wink:

Great work though @studiozellige. Some really nice ideas. :+1:

2 Likes

Would love to have this, too. With this, you don’t have to drag and drop all the time, but have a move up/down button. Preferable also with a keyboard shortcut :stuck_out_tongue:

2 Likes

Seems like more of a power user function. I’d rather leave that out for novices – and keep button clutter down to a minimum of the most important functions.

But that’s the perfect sort of thing for a keyboard shortcut. If you add it the buglist I’ll put that in. Keyboard shortcuts are easy and have almost no side effects. :+1:

3 Likes

“Oh, this is fun! Thanks for all the hard work. I know how much time this stuff can take. I really appreciate you putting so much effort in.”

Thank you Isaiah for your long answer: it’s really nice to have so much listening with the long post you wrote and also to better understand the stakes of your development. Oh, I forgot, I want to apologize about the quality of my writings: I am French and I use Google to perform the translation. Any excuses for any misinterpretation.

“Even if I don’t use some of this – I still love that you were thinking about this stuff and I take every bit of this in consideration. In other words, this info will absolutely become part of future designs – but probably mixed together with a dozen other great ideas in non-obvious ways.”

I am perfectly aware of that. My proposal is motivated only by the desire to think about a problem of user interface and as I still work a little under RapidWeaver and only with the Stacks (and I groan to always have to unfold / fold to have the best situation “geographical” of my interventions), I launched, without a second thought, for fun! … It’s up to you to do what you want. And in fact, it is a real challenge to have to create an “offline” editing interface drastically different from the “inline” preview … and if I had a wish, it would be that RapidWeaver offers one day the possibility of being able to edit, in PREVIEW MODE, the contents TEXTES or IMAGES … it would be very comfortable for the users … but it is another debate.

“One thing I should probably point out: building user interfaces in native MacOS apps is non-trivial. Even in a UI like this that is largely composed of CSS, it can still take months of work to align the native components with the non-native web-based components.”

I imagine, while absolutely not competent to appreciate the difficulty of your work. I stayed at the creation of interfaces, 2D vector Illustrator, imported into Flash to add interactivity, timelines, some pointers and animation! … Yes, it’s from another age, it was twenty years ago now! …

“Most of the UI work for Stacks was completed over six months ago. I’ve still been refining some toolbars and button colors, especially for dark mode – but changes as dramatic as you’ve proposed would definitely take months – so I’ll probably just have to file these suggestions away for the next big UI overhaul in Stacks 5. But… you never know… sometimes I can sneak one or two things.”

I did not know you were working on an update to Stacks - I can not wait to see what improvements you will make. Is there a way for me to participate in beta testing?

“OK, feedback. Here’s what I love:

2 - I love that you tried to keep it real and used a titlebar height that’s very close to the real height (you’re about 2px larger).”

In fact, I imposed myself to be as close as possible to the existing so as not to confuse the habits of historical users. On my model, the vertical spaces are identical to the current version of Stacks: I just added a pixel or two to the selected capsule, a story that visually it is more present compared to others. I also tried to colorize it in black so that it is even more pregnant! … It was not especially “sexy”! …

“OK, some critiques:

1 - So… 28px is the max – with at least 1px of top and bottom padding.”

I had not imagined that this height constraint was paramount in the development of your software. But maybe you could lower this constraint by the fact that the user would not have to unfold ALL these STACKS, and therefore gained height, because he would now have more information directly readable on each one. they, FOLDED!

“5 - Placing the X away from other controls is very important. It’s a destructive action so doing all we can to help the user avoid accidental clicks is a good thing.”

I confess I never understood why a function as important as the DELETE did not automatically invoke the display of a confirmation dialog! … An option that could be deleted in the Preferences of RW.

“7 - The title edit button. I kind of think this one might be better as a setting in the info panel or directly clicking on the title. Stacks 4 will put it in the info panel. Mostly because direct manipulation would mean a second click on the titlebar – which already has the meaning of editing the content.”

I was going to offer you this solution of the double click! … Moreover, there could be more opportunities with the contextual click … but maybe the development in CSS makes it difficult to put implemented.

“7 - The title edit button. I kind of think this one might be better as a setting in the info panel or directly clicking on the title.”

Where, again, a simple double-click! … More natural.

“7 - Stacks 4 will put it in the info panel. Mostly because direct manipulation would mean a second click on the titlebar – which already has the meaning of editing the content. I’d rather not over-laden the gestures with too many things if I can help it. I also think there’s room for adding other user-customizations (like color – but even more stuff) that might be challenging to squeeze onto the titlebar.

Lastly, and this is the big one…”

If I had to argue about a relative progress in the complexity of the user interface, I would say that habits are taken relatively quickly. And then, RapidWeaver and Stacks are old software today! … :wink: And there is also the possibility to offer two modes of interface: beginner and confirmed.

“Lastly, and this is the big one…

All of my original designs for Stacks 3 looked almost exactly like your first proposal (with circular buttons). And it wasn’t merely design. I spent months implementing it and preening the details as well. I went all the way through creating the real UI and sending it out to testers. I’m afraid the results were not very good. And that’s putting it mildly. In fact they were so bad that I had to trash the whole idea, delay the project 3 months, and start again building out different toolbar ideas.”

;-(

“To be honest, I was totally crushed. It seemed like such a great design. It looked amazing. It created all kinds of new opportunities for directly manipulating each stack. And it eliminated so many toolbar buttons, and placed so many things exactly where the user needed them. But alas – no matter what I tried, most of the buttons were just too foreign and people could not figure them out. I had to change course.

To be honest, I debated telling you this at all. I know how finding this info out made me feel and it was not good. I tried so hard to force this design on users in a bunch of different ways. I really wanted to make it work. Not to mention that I had no backup plan – and it meant a huge redesign task and delaying the project. And I was frustrated, sad, and disheartened when I couldn’t make it work. And maybe, being a bit honest for a minute, I might have been a bit disappointed in users – I wanted them to love this – I wanted them to try harder to get it – but I just couldn’t make it happen. For me this was crushing – and I really hope that you don’t feel that way hearing this too.”

Sorry for you in front of so much misunderstanding and frustration: it’s a shame. Yet there are many examples that demonstrate the opposite. Remember the reaction of users with Firefox and Safari when their programmers have decided to use the same text field for displaying the url AND entering text for search! … It may be necessary insist, perhaps, and again. But here I am not in your place, unfortunately. :wink: Good luck for the rest of your work. :wink:

3 Likes

Soon. I have just completed the developer beta milestone – and will send that build to the stack developers for testing. There are more bugs to fix and the developers will undoubtably find twice as many as I’ve found. Once those are done I will send out a public beta of Stacks 4 on my slack channel. http://slack.yourhead.com – anyone can join the slack channel and participate in the beta testing.

I’m also going to try to do some more videos or live-streams of some of the new features in the near future, so watch for announcements or follow me on twitter

I’m pretty sure I get what you were trying to say… but oh man, that is the funniest google translate I’ve seen in a while.

BTW, I speak a bit of french. My reading comprehension is not too bad. If you want to write back in French that’s fine. I can always use google translate for the bits that have technical words I don’t know. :slight_smile:

very true!

In macOS the rule is that a destructive action should either be undo-able or there should be a dialog. Never both. All the layout actions in Stacks are undo-able, so there is no need for a dialog. Dialog boxes slow down the user.

However, destructive actions – even when you can undo them – should made made to stand out and be as clear as possible.

As Stacks has matured, I’ve added more and more features for pro users. And for people that know a little about HTML and CSS. Stacks 4 will continue this and continue to add a few more of those features. However, those feature MUST but well hidden from novices. Novice users still make up the largest group of my customers – so it’s important that Stacks is, first and foremost, a tool for that group. It can still be a tool for pro users too – since pro users will explore a bit more and look for the hidden features that give them the extra power they need.

It’s hard to understand the meaning through the translation of this one. But if I understand correctly you’re referring to when users initially did not like the combined URL/search bar. To be honest, I still do not like it. :stuck_out_tongue_closed_eyes: And I think it still causes significant confusion for novice users. But… I understand your point. Sometimes it’s important to have strong opinions about your software and disregard the complaints of users – users never like change.

I agree, and I have already factored that in. It may not have made it through translation, but I did try to push through. But in the end it wasn’t so much that users did not LIKE it – it’s that they couldn’t USE it. Small icons look great – but they make things very difficult to understand unless they are labeled or are so obvious that they can understood the first time.

I think there are good reasons to break the rule to avoid small icons. There are a few in Stacks 3 right now – and there will be even more in Stacks 4. But in Stacks 3 the one real mystery icon (the pin inside a partial) is meant to be used more by expert users – and a novice user can use stacks to build a whole site without ever having to learn what the pin does.
Stacks 4 will have a few more unlabeled small icons – but they’ll be the standard Text-Editing icons: bold, italic, etc. I think most of these are standardized enough that the majority are recognized immediately. And the few that are not immediately clear are not nearly as important. These will be part of a new editing UI for Stacks 4. I’ll let you see if you can figure out the few that are not explicitly labeled. :wink:

Pasted_Image_3_2_19__9_08_PM

oh, boy – the jpeg conversion seems to have made that nice retina image very blurry – rest assured that it will look very crisp and beautiful on a retina MacBook Pro.

1 Like

These are much like the settings I’ve built into the Group stack in Foundry, along with a few others:

44%20AM

In addition when you use the Collapse Content in Edit Mode you get the option of having it display a custom chosen icon in Edit Mode for easy recognition when scrolling through the page while the content is collapsed (or folded).

20%20AM

1 Like

Thank you for all your feedback … :wink:
Finally, here is a final proposal for the Information Panel, a direct reflection of the first part. The idea is to propose, directly, a state of Stacks, with concentration of parameters …

This is the current Stacks Letterpress Information Panel, open:

The same folded panel:

Here, a proposal of the Closed Panel with little directly visible information and a better identification of the Stacks:

The same panel unfolded:

… with two options unchecked:

And a last option with more information on the state of Stacks, without having to unfold the Panel:

1 Like

OK, just quickly responding:

  1. I’m not sure I understand the purpose of the red X.
  2. The stack icon in front of the tile is something I’m working on. While it’s not yet in a real build, I’d like it if I could make this part of Stacks 4. It may be, but no promises.
  3. I like the color family. I’ve been trying to think of ways to make that work in the Stacks API. I’m all ears for proposals. I think pallets, families, etc. might be nice additions. But how to connect those in an elegant way to a Stacks API variable is non-obvious.
  4. The size of the color control is probably problematic. In most cases, I’m trying to find ways to make the controls smaller, not larger. Currently the sidebar does not offer nearly the needed information density of a pro app. Just like the extra pixels around the capsule, this is something I think about a lot. Each major version of Stacks has increased the information density of both the layout and the sidebar while trying not to affect usability too much. It’s a balance, of course – it means sometimes removing extra whitespace, sometimes adding more controls horizontally, and sometimes building completely new controls. But I probably won’t make any controls larger than they are today.
  5. I do not like the icons in front of the control titles. Too many icons, like too many signs on the highway, just become a jumble of meaninglessness. I’d rather save them for strictly utilitarian purposes. I also think this sort of UI is too unique and too new – no other apps that I know of use dynamic iconography in this way. Sometimes new things can make a UI easier, but often the unfamiliarity just leads to confusion.
  6. The orange color in the header is unfortunately not feasible. That header is part of RapidWeaver. I find that header to be very out of place and difficult to work with and have asked Realmac to let me style or remove it, but I have not heard back from them regarding this. If I could style this header, I would make the entire top bar a single unified toolbar that is more integrated with the top toolbar. I really really wish this was possible.

Hello Isaiah, the red cross offers the possibility of removing the Stack. The idea was to offer the same functions everywhere, in the publisher area as in the Information Panel … but it may not be such a good idea after all …

Below, following my reflections “nebulas” on the interface of Stacks. The constraints that I imposed myself are:

  1. The first (general) parameters of the Stacks very often seem to be the same, whatever the Stacks (Background, Border, Layout and Responsive): why not install them in the same sub-panel (General Settings)? …

  2. Display a maximum of parameters for the user, directly, without having to force him to click (I find that in RW, one does not stop to click to fold and unfold interfaces! …),

  3. Reduce the number of user clicks,

  4. Minimize the height of the settings.

Here is the current interface:

Then, the interface with additional parameters:

Here is a proposal taking into account the constraints explained above:

… and finally, the displayed parameters:

1 Like
  1. while these are both very interesting ideas the four sliders are very easy to understand and are designed specifically for “onboarding” users and helping them get comfortable with the idea of the sidebar.

  2. because stacks is build to be 100% expandable through the stacks API all controls must be reusable in many applications. full custom things are probably not possible.
    that said many 3rd party stacks need similar border controls. there might be room for something like this as long as it was very carefully designed.

  3. short labels that wrap to two lines: nope! not doing that. LOL :joy: sorry just a style thing. it’s not terrible— it’s just my personal preference.

1 Like

Hi Isaiah, thank you for your return.
Whatever the consequences of these proposals, I had fun thinking about these interfaces.
Good luck for the rest of your development …
Cordially…

1 Like

Thank you both for such a fascinating conversation, particularly @isaiah for being so candid about the practicalities of UI design and functionality. I use stacks very heavily, so the insight is really appreciated.

I have but one simple (to me) request: the ability to select multiple stacks for move or copy & paste.

I’m sure everyone asks for this :wink:

3 Likes

+1000

4 Likes

A very interesting discussion!

Very interesting discussion indeed.

Must say I really like the suggested Border and Layout controls from @studiozellige, much better to visualise what you are doing with those controls.

Almost thinking of suggesting even a minor reordering of the current controls, more in a sequence of how they are used with the more commonly used controls first rather than hidden further down the side bar pane.

Might have a play with this later (really shouldn’t but it’s quite tempting) to try and come up with a layout to illustrate what I mean.

Oh that seems like really good feature @isaiah

:smiley:

1 Like