Improving the Tab Behavior

[ardeay]

Tabs are a feature of the Zesty manager that were put in place to create fast switching between two working environments, like a code view and a content editing view. A tab is created for each experience (unique url) a user visits in Zesty, they stack left to right. When a tab is clicked, a user quickly jumps back to their previous working environments. Tabs were created because the developers witnessed that users would often keep multiple web browser tabs open to edit their zesty manager. Keeping multiple tabs open is problematic because state changes to the data won't always be updated, which can create issues like version over written or updating stale data. Tabs were designed to behave like web browser tabs.

Tabs get unruly quickly as their a so many views in any given Zesty manager.

We Want to Hear Your Feedback!

We have heard many complaints about tabs: too many, lose track, don't work with multi-lang, etc.

Please share your ideas on how to improve the Tab experience.

Example of Tabs

Tabs are on the top of the interface

Tab bar view

Close up

Close up with an active tab

[giseleblair]

A pin icon or some sort of action that would create a tab. Rather than having tabs stay put automatically. An auto-generated tab creates unnecessary clutter in the tab navigation that the nav itself becomes cumbersome to use.

[ardeay]

That's a cool idea! On how its implemented, would it be in the editing experience view, some sort of button top right or left that lets you pin? Or would it be a pin on the tab (but the tab would go away unless its pinned?)

[giseleblair]

I think a pin on the tab itself. Having the currently active tab is helpful to see what item you are currently on. So keeping the tab experience in the navigation itself makes sense to me

[ardeay]

What do you think of a solution where are always 3-5 recent active tabs plus any tabs that have been pinned in addition?

[giseleblair]

I think just the active tab and any pinned items would be good. If anything having 3-5 recent tabs would cause the same issues. If a user already has about 5 tabs pinned, then the recent tabs would cause clutter again

[ardeay]

Good points. I'm thinking through the implementation. What do you think of a max of 5 total tabs, with a max of 4 pinned tabs, given the 5th one is always active? At any given time there would be max 3 recent, if there was room.

How I'm imagining a solution like this is there would be no x (close) on the tab, just a pin icon, unpinning a pinned item would pop it off the queue unless it was the active tab. If a tab is not pinned, it falls of the queue as the user browses around.

[Katiemoser]

I honestly never use them, with them being dark with blue writing, I don't really notice them or think to use them in my workflow. I'm more inclined to navigate through the sidebar, so I agree with Gisele that it might be good to use it as a pin feature that people can save their most-used pages to easily navigate to.

[bltarkany]

A dropdown with a search, similar to VS code's go to file - where it shows the items pinned from Gisele's comment above and/or shows recently viewed files. And the ability to remove them from the dropdown via the X. Could possibly extend this out to include a search. The dropdown would keep the navigation free of clutter

[ardeay]

That would be great for search.

[dhakimzadeh]

The problem with tabs

• NO SIDE SCROLLING, ever, side scrolling is the worst when not using a mac trackpad <--

-- when enough tabs are open to necessitate side scrolling, it becomes easier to just use the left columns again
--- one solution is to just limit tabs , but i dont like this

--- TAB GROUPS ---
another option is to condense them into dropdowns under more global tabs like, CONTENT, MEDIA, SCHEMA, CODE.

this way, if i open 3 code templates, 3 content forms, and jump to a data model, then jump to code, then after want to enter content on my form, i can immediately find the content form i was just on under my content tab dropdown, like tab groups with chrome, just more automatic,

groups would save me from clicking a multi item model then finding my item, i could just keep that in tab history under the content tab etc etc

the only problem here is:
if I go to content,
click on Articles,
then click on the article i want to edit,
then click on code and click on the code file i want to edit,
when i go up to the dropdown for content, i would see Articles AND the specific article i want to edit

this is precisely what is causing so many tabs now, in reality, i dont need Articles to be there cluttering up the tabs, i just need my specific article -- only solve i can think of here is to manually choose what becomes a tab, but that doesnt feel like the best solve

what might work is limiting tabs, but also allowing pinning tabs like described above, but youd pin them to the tab group...

this way regardless of window width, your tabs are all there without sidescrolling to get to them ( global tabs could just use the icons if the window gets too small)

[ardeay]

@dhakimzadeh for tab groups, are you imagining it like a traditional toolbar?

[dhakimzadeh]

more like the mac dock with the open windows

although I do think a traditional toolbar might work for the far left nav

[ardeay]

ahh gotcha, so when a user would hover or an icon (say) schema on the left, it would give a flyout like this with latest opens?

[ardeay]

@agalin920 check this out

[dhakimzadeh]

yeah exactly, whether its top bar or left bar doesnt matter much. the mac dock is probably the best example, just swap in tabs for open windows :)

[ardeay]

In conclusion, the idea is when the user hovers over an app on the left, it has a fly out of most recent items visited there. This is good because if something in schema was worked on 6 clicks ago, it wont be in the tabs, but it will be seen in the most recent flyout. Making it so you are always 1 click away from your most recent schema edits, but without the clutter.

[jjnotjayjay]

@ardeay

I love the Zesty platform as a whole! But won't mince words below.

Tabs in their current form on Zesty are, essentially, unusable.

On a mature Zesty instance (with hundreds if not thousands of content items), as a user navigates between content items, the number of tabs continually increases, to the point where the number of tabs inevitably extends beyond the viewport's available width, leading to a scrollbar. (Because let's face it, it'd waste more time than it'd save to have to close a Zesty tab every time we switched views.).

So for one example. Say I worked on something 2 weeks ago, and its content view is thus now buried as a tab off the screen to the right. I log into the Zesty instance to make some changes to unrelated content. I open up a few different content items (opening up new tabs in the left-most portion of the tab group) and see them reflected. I then have to make a change to the content item I edited 2 weeks ago. The moment I open up the content item, the tab for that content item is opened up, auto-scrolling the tab nav to that item, and just like that, the tabs for all the other items are no longer in view. If I wanted to get back to them, I'd have to scroll either in the tab bar (difficult as I develop on a keyboard and not a trackpad) or just scroll to the item in the content editor. I imagine most if not all users simply scroll to the item in the content editor.

Naturally, it'd be a bit ridiculous to expect the user to keep track of the visibility and location of every tab that is currently up in the tab interface as the number of tabs continually increases, so for all intents and purposes I simply ignore the functionality.

The best idea I believe I've had to improve the functionality as a whole is also one of the simplest: always open a new content item in the left-most space in the tab bar, unless the user opened the content item by clicking on its tab.

Put another way, organize the tabs always by most recently opened (by a means other than navigating via its tab). So if I go to edit a new schema, a tab for the schema opens up in the left-most space. I then open up an associated content item. It's now in the left-most space, pushing the schema to the second space. I make some changes to the content item and save. I realize I need a new schema field. I click the tab for the schema. Both tabs remain where they are. I make the schema changes. I navigate back to the content item by its tab. I add the content. I open up a new unrelated content item. It's now in the left-most space, pushing the content and schema further to the right.

I think this approach would solve most of the issues with tabs. It eliminates the need for scrolling, and makes the behavior very predictable. Users don't need to keep track of where anything is.

If they were organized like this, I think they'd be very useful and I'd actually use them.

If this was combined with the ability to drag and drop a tab into a desired space, I think tabs would be phenomenal.

[ardeay]

Thank you for the feedback @jjnotjayjay

The left most loading for most recent makes sense. If you see the other user posts about pinned items, maybe pinned to right, most recent to left, the 3rd most recent pops off the stack.

After reading every comment here, its starting to click that the solution will be a mixture of this feedback, which is great!

[jjnotjayjay]

I don't imagine I'd use pinned tabs, but another option would be to have all the pins in a dropdown that appears when the user hovers over a "pin" icon (on either side).

[shrunyan]

I agree with @jjnotjayjay suggestion. To me though it begs the question what is the more common use case;

• Recency. Quickly getting back to the last few views you had open.
• Recall. Being able to bubble up(pin) a view so as you work it's ever present and can be quickly returned to.

[ardeay]

It's clear the current tab setup is poor and needs an improvement, based on your feedback I mocked up these concepts as a proposal for development. Comment or upvote if we should work these into production.

Tab Pinning

ty @giseleblair for pin idea
ty @jjnotjayjay for left to right stack push

App Recent Flyout

ty @dhakimzadeh for the flyout idea

[jjnotjayjay]

@ardeay Feedback on the proposals below:

Tabs:
I'm not a huge fan of the number of tabs being that low (or even a fixed amount at all). I think the number of tabs should continue to fill up the horizontal amount of the viewport - it just shouldn't go beyond it. So perhaps the most 10 recent tabs are saved, and the number shown is viewport-dependent.

With similar reasoning, if a user hasn't pinned any tabs, there shouldn't be space dedicated to pinned tabs.

Personally, I'd be completely fine without any pinned tab functionality since I imagine there wouldn't be a huge UX improvement over simply making it recently visited and on the left (after all, the user would be able to easily re-access that content item after their first visit), and fear it'd introduce unnecessary complexity. I'm not against it though and could see it being useful, potentially (though not for any of the instances I work in) - I just worry that it might clutter or complicate the tab interface until the point where it's not particularly usable again.

Flyout:
I am personally strongly against this idea as it feels duplicative to me, if tabs are organized by most recently viewed. I personally believe it would over-complicate the UI of the Zesty admin app, with very little marginal improvement. At a minimum, I'd request this functionality be able to be turned off.

[shrunyan]

I concur on fly outs being undesired on the global app menu. Beyond @jjnotjayjay points, this could also just be interactively problematic. As you may intend to click on the global app menu link to load an app and then quickly mouse over to where you know that apps nav will be. But you will have triggered the fly out which would lay on top of that area in the view port possibly preventing you from clicking on the app nav link you need. Requiring you to hover away and then mouse back to the link. I think this would be extremely frustrating.

[ardeay]

True @shrunyan, the operating systems skirt that issue with input, on windows a right click gives you a flyout, on make a hold click. Both would be slick.

[ardeay]

@jjnotjayjay it would be easy to limit tabs to your view port with some simple division, making it not fixed to 3 but (width-available / tab-width)

[shrunyan]

Discovery, Organization or Recency

How are people perceiving the purpose of global tabs?

Is it about being able to discover items? Probably not, this would make more sense for the global search. Meaning you are wanting to work with a particular item and you need to find it amongst all the other items. This would also include a scenario where you are wanting to work on an item you have never viewed before. Therefore will not be recent and could be deep on a long list of items.

Is it about organizing your workspace? Meaning you know you have to work on a web page which consists of a schema, content and code. You need to quickly jump back and forth between these views. Therefore you want these currently relevant views collected together.

Is it about recency? Being able to quickly hop back to the last few views you were working on. I could see this being the case in 2 scenarios. One when you are returning at a later point in time to the product, .e.g. The next working day, and you want to quickly return to the last place you were to begin working again. Another which is as you are working you want to be able to quickly return to a prior view.

This was the original intent of the tabs. With both scenarios feeling like they are poorly served with the current experience.

My conclusion is that discovery is better served by a global search. Recency was the original intent but seems like it does not fit day-to-day workflows. Organization sounds like the true underlying need.

To this goal of organization. I suggest we combine a few of the already mentioned ideas into a cohesive solution.

1. All "tabs" are manually added. This creates a tab "group".
2. Each tab group allows for an "add" action. Which would add the current view to the group.
3. Allowing for users to create groups of views mapped to their organizational needs.

Overall the questions I am hearing we need to answer with any solution are the following;

• How do I get back to the prior view(s)?
• How do I find that item I was working on?
• How do I quickly switch between related views? E.g. content, schema, code
• How do I reorient myself when returning the next day?

E.g.

[ardeay]

My opinion is the more the computer can do for you the better, which is why I dislike only groups since they require user input outside of a click. I do however like the ideas of a group option, where you could group a model/item/view or whatever you wanted, and name the group. Like a working tab or something of the likes. Some zesty instances have 60K content items, some have 50, very different use cases to consider. Bigger sites with power users, I imagine, would lean towards more control over the interface. Though the idea feels novel, and would be cool at first but would too much work to build up and tear down, which would leave users with dead tab groups. That is why I go back to automation building recent accessed along with user interaction to pin.

[jjnotjayjay]

Well, yes 40-50% for some instances is the use cases I outlined. The other 50-60% of the time though, I'm developing new pages and would use tabs heavily if they were organized sensibly (i.e. most recent left), rather than opening things and have the tab bar horizontally scroll/jump around.

Discovery feels like it should be solved by the Global Search function. The ability to find a string of copy via Global Search would be very useful, for example.

Sure, in a perfect world marketers find what they're looking for all the time, and choose to invest the effort to do things themselves. Often time that simply doesn't happen - other times they can't be blamed for not finding something. For example, the current Acorns instance for dot com has 214 different schemas, so I could see it being tough to find something once in a while. (And that's leaving the "In-App" instance alone entirely, which is borderline unusable at times due to its size (even for me, it takes a lot of poking around).

In instances where my team or I have created everything personally, this is less of an issue (if an issue at all). But there are instances that weren't carefully thought through during creation, which is where discovery becomes an issue.

Again, though, that's a completely separate conversation and I personally don't view tabs as a way to tackle the problem of discovery (at all).

[shrunyan]

We could possibly combine all of the feature concepts; recent, pinned, groups

Space is an important consideration as it is very constrained but fly outs may resolve that. Overload is another consideration. If it becomes a bar of icons(actions) that maybe overwhelming.

For example

[ardeay]

@shrunyan How are items added to a group?

The combined one would likely make power users happy :)

[shrunyan]

I imagine on the group tab itself there would be an action which would add the current view(i.e. URL) to the group