updates to the ui

[scottaohara]

I saw the issue that was open about updating the UI. I thought I would take a real quick pass at it and offer up some basic styling to at least make the select elements more noticeable as well as making some helper classes to more easily style the buttons and rows in the UI.

[ondras]

Hi,

I would love to see some design sketch (to check the whole UI concept) prior to actually implementing stuff. For the sake of consistency, I plan on changing the CSS myself - which means I am basically looking just for an image/mashup/etc.

As for your pull request:

1. why the href="#!" ?

2. what is the point of having both "btn-row" and "ui-row" All the buttons obviously center their text content...?

[scottaohara]

Thanks for the response.

Per your questions:

1. That's just a best practice I implement so that empty <a>'s don't kick you back to the top of the page on click. Adding the ! after the # makes sure that won't happen without the need for JS overwriting the default function of a link. You probably already have something in place to take care of this, it likely could have been left out, or the <a>'s could be changed to and then it'd be a non-issue as well.
2. .ui-row took the place of the .ui p {} selector you had in place, switching the p's over to <div>, as they aren't paragraphs. .btn-row is a helper class for the button rows specifically, to apply the text-align: center to the entire row, as opposed to just on the buttons' text. this made the buttons truly center in the column without having to rely on padding to do that. As if you resized the current live build of My Mind, the button layout would break.
   

My fixes make that not happen, as well as adding the borders to the elements, and changing their value from a hard pixel input, to a width of 100%, (the box-sizing makes the padding not send some of the inputs off the edge of the screen) -- here's a screen shot of what my changes look like. (it's really not much, just a little bit to help out until a firmer design vision is put forth) A broader answer to your second question is that it's a lot easier to maintain a set of base classes that perform specific styling functions than it is to have very specific selectors targeting HTML elements. Within this example again, I wanted to make sure the buttons were always centered within the column. If I applied that to .ui-row{}, or your original setup of .ui p{}, that would have applied it to everything, which wouldn't have been desired. I hope that helps explain some of my decisions better (and the screenshot shows that I didn't go off the rails with a redesign). I'm sorry to hear that you're not interested in taking code pull requests, but I hope that this will end up being helpful to you in some way. Take care.

[ondras]

Hi @scottaohara,

thanks for a precise explanation!

The #! href value is a red herring, imho. I just tried it with a blank page and one such anchor - clicking it does indeed propagate the #! value to the URL (without preventing that in JS, obviously).

I see the purpose of .btn-row, that is neat. I never expected the UI pane to overflow, but some recent additions caused quite a lot of new content to appear there, so this is now indeed possible.

Thanks for the attached screenshot; I naturally tried your code, but my experience was a bit different:

This is a platform issue - selectboxes have some gray background on my Ubuntu Linux desktop.

This is why I prefer an image over a pull request (in this particular case): by iterating over the individual form element design (mostly: button, text input, selectbox), I hope we can converge to a final design without having to resort to repeated CSS-changing commits.

Anyway, I'd like to thank you for both the design (and pull request) as well as the explanation. I hope we are going to finalize this in a consistent manner. In my opinion:

1. the colored buttons are nice, but I see no pattern in the color choice. Also, there is quite a number of other buttons in the Save/Load pane. I do not want the app to look like a rainbow in the end;

2. selectboxes obviously need some love;

3. text inputs (there is one in the Firebase backend config) are unstyled as well;

4. individual <h3> elements are styled, but I am not sure if their saturated background color is consistent with the overall application look.

What do you think?

[scottaohara]

I'm glad I could add some clarification there. I apologize for not including more information within my initial request.

In response to your list:

1. yes, i agree. I think it'd likely be best to create button classes that apply the appropriate button coloring, rather than them being applied by row (I didn't change this in my pull request cause I didn't want to go very far down that road...but with this discussion i think it's a good time to bring the idea up.)

I think the styling of save / save as could be transferred to a .btn-save{} class, and the new / load should take on a second btn-NAME (i'm not sure what to call it yet). All other buttons could have a simple class of .btn to apply a base button style. (something different than another shade of green or blue.)

then there would be 3 button styles that would all have very distinct colors associated with their actions
save/save as = color 1
new/load = color 2
other action buttons = color 3

that'll keep it from looking like a rainbow and also keep like-action buttons from having their colors changed.

1. The select buttons could just have a background of #fff set and that should hopefully make them consistent across all browsers/platforms.
2. It might make sense to create a global selector of .input, .select {} or more generically .ui-input {} that could be applied to either inputs, selects or textareas, to make sure that these elements appear the same across the entire app, and not have to repeat styling for things outside of the .ui container.
3. I agree that it would probably make sense to tone those down a bit. I think the idea behind them works, as it clearly delineates the different sections of the UI, but they could be done more subtly.

I'd be happy to work on these some more after I get out of work tonight, if you agree with my general thoughts here.

Thanks!

[ondras]

Yes, I agree with your points.

I am somewhat in favor of (more elaborate) CSS selectors to prevent redundant HTML classes. For instance, the (backend-specific) "save"/"load" buttons are all reachable via button.go etc. Similarly, all UI input elements are available as .ui input, .ui select, .ui button.

[ondras]

Just to re-iterate the main message of my previous post: I think we should focus on the target appearance first, and discuss implementation details (such as class names and so on) once the look is settled.

[JanecekPetr]

Did you consider putting some icons on the buttons? Save/Load, Help - those could definitely use an icon. If chosen well, they would greatly reduce the confusion between the button groups, no colored groups needed. There are thousands of free icons all over the web. E.g. https://www.iconfinder.com/

[ondras]

Icons would be nice, yes. But to maintain consistency, it would be best to have them as a part of the UI-redesign, i.e. not blindly added (to the current UI) just for the sake of having icons.

[voronoipotato]

I would really love to have a button to change the background color of the mind map if we're reworking it, and why not have a color picker instead of just 10 arbitrary colors? Or at the very least 9 arbitrary colors and a "custom color"

[ondras]

@voronoipotato Because the goal here is to make the UI simple. The picker is absolutely useless for 99.99% use cases and confusing for many.

As for the background color, I guess this fits my design plan of allowing a custom CSS styling. I would argue that a typical user has little need to change the background color, if the default value is picked reasonable (which I am not sure the current color fulfills).

[scottaohara]

it may make more sense to have 'themes' as opposed to a wide open color picker. the option of choice while keeping things still looking good.

[voronoipotato]

@ondras you can make a tool simple without cutting out more intimidating features, simply have an "advanced" pane not saying that you should necessarily spend time on that but lets not make this a battle for usability against usability.

@scottaohara yes, I completely agree. Can we also please change the default theme, I find the plane of pallid flesh nauseating. Is that just me?

[voronoipotato]

Okay every time I open up My-Mind I find a new thing I don't know how to do, and it's very very irritating. There's checkmarks and x marks I don't know how they're made, I don't know how to bring up the help, and frankly I feel helpless every time I open it. 😭

We need more indicators. This project has almost no affordance. 🍵

http://en.wikipedia.org/wiki/Affordance

That all being said I'd like to know who your intended audience is.I feel like you're pandering to a demographic that doesn't exist, or is so niche that they'll never find the project. I'd like to help you get to a more usable product.

[ondras]

@voronoipotato I am sorry to hear about your troubles. Some users find the "Help" button (situated in the only area with buttons) convenient; other simply hit the "?" key, which does the same thing.

Finally, all features are documented on the GitHub page, which is also available from My Mind's UI (the GitHub logo in the bottom-right corner).

Have you ever used any other desktop-based Mindmapping software? I tried several of them and I find My Mind (both UI-wise and featureset-wise) arguably far simpler. Yet these programs are used by quite a number of users. I am not sure how to describe them (the users), but I definitely fit within this group.

[ondras]

Also, it might be worth noting that while the project was visited and tried by tens of thousands of visitors (since its launch last week), you are the first one reporting such issues. It is hard to tell whether the others were too lazy to report their experience or not.

[voronoipotato]

@ondras It's important to remember as long as you are currently involved you will be too close to the product, as you have learned many of the usability patterns through repeated use. That doesn't mean they're more or less usable of course, it just means that you're numb to any normal hindrances to learning the product.

I think yours is faster once learned, but there is a learning curve I think we can cut out without losing the brevity you enjoy.

I'd say your current targeted group just kind of a "guess" would be 20-30 yro comfortable with technology and academia. Which is honestly a HUGE chunk of the people who use these kinds of software (i'm one of them). Specifically they aren't afraid of technology, which is why you can take advantage of the shortcut heavy layout.

That doesn't mean that the shortcuts make immediate sense, which I don't believe is your fault. It's simply a lack of affordances and alternatives.

For example I love to use VIM, a modal text editor, but it has incredibly niche appeal due to its steep learning curve. When G-Vim came out it converted many people to vim, because the learning curve was shortened and softened. Now instead of remembering long strings of nonsensical commands they could use the slower more comfortable menu driven edits, (with the commands next to them). This enabled people to learn the software without being dropped into a black abyss of productivity loss. As they grew to use the software more they used the menus less and less until they no longer touched them.

What I'm saying is this product might need training wheels 🚲

[voronoipotato]

Also users will almost always be too lazy to report when something is hard to use, or broken. The reason is they blame themselves for not being able to use it. Primarily a user will only blame the software when the software is clearly not at fault.

This is because a person doesn't like feeling helpless so they'd rather invent a story that explains why it was their fault.

They also don't like facing when they've ACTUALLY screwed up so they'll invent a story why it was the computer's fault.

The person KNOWS unconsciously whose fault it is, but facing that is frequently too much emotion for such an inconsequential activity.

The only ways I know to get a user to fess up is by either begging them to criticize, or paying them to complain. (Or someone like me who complains about everything)

[JanecekPetr]

Wow, finally someone. He's right. Since I also am a part of the target group, I eventually figured out what should be done.
However, I tried a lot of different things first - I looked for Add new node icons, I tried right-clicking on the canvas and on the nodes to bring up some useful context menu. Only after that I tried the hotkeys I knew from different mind mapping programs.
I have no idea what would I do if I knew nothing about mind maps and had I just read about them on wikipedia and googled the first tool for creating them, I think I would be helpless for quite a lot of time (until I opened up the help).
Also, I consider myself to be a power user and I do programming for a living, and I still had to play around with Number and Yes/No values in My Mind for a few minutes in order to completely grasp the way the features work.

TL, DR: It's not as intuitive as it may seen to be and it would use some UX improvements. However, I am in no way an educated person to design them.

[ondras]

I believe we are able to handle this in a constructive manner using a scientific method, instead of a general whining about a counter-intuitive UX. Let me start by de-constructing the recently shown points (some of them not truly relevant to this particular Issue #36):

1. Context menu (right click) is a feature that I already acknowledged in one of out previous discussions. I am curious why there is not already an issue opened for it? I find it useful and am willing to implement it.
2. "Training wheels" is a sweet term that somewhat corresponds to Issue interactive tutorial #6. Once that is done, we can educate our users instead of scaring them.
3. Menu icons for adding new stuff (the kind @JanecekPetr was looking for) might be easy to use for newcomers, but frustrating to see for regular users. They obstruct visibility and are really useless once you start working with mind maps on a regular basis. Moreover, there is an open Issue Support phone/tablet touchscreen operation #27 that discusses alternate approaches to adding nodes; something - IMHO - far more useful than a Word-like toolbar.
4. I expect My Mind users to have some prior experience with mind maps. I am having some difficulties imagining a newbie user who never heard of mind maps but totally wants to use this app. Therefore, a typical user knows what mind maps are and what features they generally offer. At the end of the day, all mindmapping tools do the same stuff: they create and visualize linked tree structures. And trust me, once you dive into mindmapping, you will never complain about a keyboard-only control.

I would be happy to discuss additional features, suggestions and changes - but please file a new issue for each of them to keep this thread consistent.

[voronoipotato]

@ondras

1. I think the right click context menu can be unintuitive for the web, as usually it's disabled or just allows you to "back|forward|reload|save as". I'd never figure out to use it, and likely forget in the future. Additionally mobile devices don't have a right click and they're one of the main groups we're doing this for.
2. Ideally one should educate through affordances and indicators, not a tutorial, exactly :).
3. Menu items are merely an instance of feature duplication. multiple paths to the same same door, I think the stuff in Support phone/tablet touchscreen operation #27 is the way to go for the most commonly used features. If that might be irritating to a regular, maybe when the mouse is moving about these show up, and when the user stops moving the mouse menus go away. Now keyboard only users will never ever see these, and mouse users will see them as much as they need to. Then add a hide/show button for the outliers.
4. People who will complain about Keyboard only control are mobile users,command keys are a pain (if they exist on a soft-key) and modal typing is a mystery for even most experienced users.
   a group that might complain is people who primarily use another program but will use yours in a pinch, that group would complain if the software differed from the program they were used to, I imagine you've been following the convention on that and won't have any problem with these folks.
   a group that would definitely complain is a group that knows about mind-maps, uses them occasionally to organize thought, but usually on paper, and doesn't want to have to figure out how to use the software. They shouldn't have to learn a set of commands just to use it. <-- me!

The whole thing that makes your project desirable to me is that I don't have to install, login, set up, or do anything. I can just make mind maps, but shortcuts are holding me back (until I learn them)

I'll try to make issues that cover specific feature requests in the future though, thanks.

[ondras]

@scottaohara I don't want to be rude, but do you still plan on delivering some re-design ideas for us?

[scottaohara]

no, not rude at all. If anything I've been the rude one in that I haven't given you an update.

I've been swamped with a bunch of other projects / family life, and I'm not sure when I'll be able to get back on this. Sorry to keep you in the dark about that...

[ondras]

Closing for inactivity. Most UI-related stuff is discussed in #35.