Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow changing the sidebar order. #79

Closed
romu70 opened this issue Feb 9, 2019 · 8 comments · Fixed by #365
Closed

Allow changing the sidebar order. #79

romu70 opened this issue Feb 9, 2019 · 8 comments · Fixed by #365

Comments

@romu70
Copy link

romu70 commented Feb 9, 2019

First all of, bravo ! Akira is a great idea.

As a designer, all tools I've used and still using (Figma, Sketch, Gravit, ...) share the same layout, basically the content on the left, and the inspector/tools on the right.

I suspect your proposed layout is to not be accused to make a copycat, but following the de facto standards is also a way to ease the adoption of Akira. Because this way, you won't break the users habits.

So my point is: do the same, content on the left, inspector/tools on the right.

@abienz
Copy link

abienz commented Feb 9, 2019

Some tools are different, the Adobe suite of tools aren't exactly the same, Adobe XD doesn't have a left hand panel, only tool buttons.

It would be interesting to do some user testing to see if there really is a preference, but in-spite of that maybe just an option to switch the left and right panels at will.

@Alecaddd
Copy link
Member

Alecaddd commented Feb 10, 2019

Thanks for your interest in Akira and for this report.
Despite your assumptions, I didn't design the UI Akira to copy or try to avoid to copy the other software.
Everything was done for a reason, trying to speed up the user workflow and remove any friction point to improve productivity.
Since the current Akira UI is not fully fledged out, I can see where your assumptions come from, so, here's a little analysis of the "whys" behind the current Layout.

If we try to streamline the user flow, we can identify 6 major interaction points with a design app.

  1. Insert a new shape
  2. Interact with the shapes on the canvas
  3. Edit the attributes of the shapes
  4. Order the layers to organize the project
  5. Create slices and exportable groups
  6. Export

With most of the time spent going back and forth between action 2 and 3.

If we analyze the UI of Sketch and write down the path and user flow, we end up with something like this:
sketch-flow
You can see how the user's eye goes back and forth from left to right, especially during the last steps of the workflow. I consider this a pretty good workflow but is not frictionless, and I found myself too often jumping between the far right and far left of the screen to reorder layers out of the way, or update the slices, before exporting.

If we analyze with the same technique the layout of Akira, we get this:
akira-flow
This ordering allows the user to constantly interact with the same side based on the current state of the project he's working on.
While editing and creating, the user can keep his focus on the left side.
While ordering and exporting, the user can keep his focus on the right side.
Less crossing and getting lost between sections.

@romu70
Copy link
Author

romu70 commented Feb 11, 2019

Thanks for this very detailed answer. FYI, I changed my first comment, because I wanted to say "to not be accused to make a copycat".

I understand your process, and the design result. Problem is this depends on the order of the process. Personaly, I think (not sure at 100%) that I tend to work on the ORDER phase way sooner than your way.

And also because I come from the development world, Sketch, Gravit and Figma are organised like IDEs, the content is on the left.

It would be interesting to try Akira and get feedbacks to decide which is better. I'll try asap myself.

@antoniofsm
Copy link

@Alecaddd, I agree with your default distribution proposal. What about, as a plus, allow users to configure their distribution? I'm not a developer, and I have no idea if the implementation of this feature sounds reasonable or not.

People like me who come from the "traditional" design world, we are more comfortable building our personal workspace, moving and switching the panels. Often, this includes a secondary monitor dedicated to locating some panels and tools, liberating space in the main screen.

All my support in this project.

@julientaq
Copy link

@antoniovicienfaure tells exactly what i feels. As a designer, i want to be able to move things around as, depending on the task at hand, i may want to move tools around. Floating/hideable panels take my vote.

@umurgdk
Copy link

umurgdk commented Mar 5, 2019

  1. Insert a new shape
  2. Interact with the shapes on the canvas
  3. Edit the attributes of the shapes
  4. Order the layers to organize the project
  5. Create slices and exportable groups
  6. Export

First of all, great project and great effort, thanks for everything you are doing. But I disagree with your user flow image. There is not really an ordered flow between those functionalities like as in web form user interfaces. Time gap between each "step" you mentioned are so big can be days or weeks. Pro users usually doesn't use insert tool buttons at all, and ordering the layers are not the next step to insertion / arranging. I agree Akira doesn't have to follow what the others does, but if there is no good reason, it is good to keep the ui similar to what the people are already familiar of.

Also when I think about the professional usage, people who are using Akira will be using sketch (or others) time to time. Many people will have macs at their work environment, and linux (with Akira) at home (or personal laptops). Changing the layout will annoy those people I am sure (count me in).

EDIT: I think it would be better if you provide this layout as a setting not a default.

@12people
Copy link

12people commented Apr 22, 2019

To preface this, thank you for all the work you are doing! I'm a supporter on Liberapay and I hope this project will be very successful someday.

@Alecaddd
I agree that the UI should reflect the user flow. However, I would argue that your flow visualization is misleading, as:

  1. "Interact" is side-agnostic. When working with the canvas, the left and right sides tend to be about the same distance away. The left sidebar isn't easier to reach, despite what your annotations imply.
  2. "Send backward/forward" and "Send to back/front" is missing from the order step. These tend to be the order commands I use most often, so it's odd to see them omitted. I personally use keyboard shortcuts here (and with Create as well). That said, their placement should ideally reflect the placement of the Artboard sidebar.
  3. "Rename" is the actual step that tends to precede exporting for me. It's important to draw this distinction, as "Rename" does not necessarily have to be associated with the artboard list. (It could just as easily live in the Properties panel.)

Also missing from your consideration are the following arguments FOR a properties panel on the right and a layer list on the left:

  1. It adheres to the standard parent > child hierarchy. As we read LTR, it's natural to have the parent on the left and the child on the right. It makes sense to have the pages and content list on the very left, the actual contents to the right of that, and the properties for the contents to the right of that.
  2. It's a globally used design pattern. This is a pattern used throughout all kinds of software, from file browsers to PDF viewers to IDEs. I can easily list lots of apps that feature a page or element list on the left, but I struggle to name software with it on the right. There's a bit more variation with the positioning of property panes, but my experience is that, again they tend to be on the right.

All that said, I agree with your points that:

  1. "Insert" should be near "Edit"
  2. "Slice/Export" should be near "Rename"

However, rather than having a non-standard panel layout, I'd suggest you solve this by:

  1. moving the Insert button to the right of the toolbar to be near the properties panel
  2. keeping the slice and export functions in the page/layer panel, as you've proposed

@Alecaddd Alecaddd changed the title Akira layout should follow de facto standards Allow changing the sidebar order. Apr 13, 2020
@Alecaddd
Copy link
Member

Akira evolved dramatically since this issue was opened, and now the code is very modular and mostly based on event and signals, making the order of widgets pretty much irrelevant.

We could add an option in the preferences panel to allow switching the order of the sidebars (a reload will be required).

This shouldn't be too complicated and it could be a good exercise for first time contributors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants