-
Notifications
You must be signed in to change notification settings - Fork 6
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
Getting started was hard #5
Comments
Very good point. Yes, I could do that. But I could also do this: In that default window I could just add a "Need help? Click here for more information" button. And if you click that a special editor tab would open that would actually not be an editor but a getting started help page. How would you like that? The [+] button seems obvious, but it has one major disadvantage: It would not tell µPIDE where the file is to be located on the device. I don't see an intuitive way to let the user specify that location at a later stage. The same goes for the button bar. In Arduino there is one sketch (which may consist of several files but it's still a single sketch). So whatever you do in the button bar relates to this entire sketch. In µPIDE you deal with individual files and it would not be obvious what a button click relates to. Where is a file being created if you click [+]? Which file is being saved if you click [v] ? All open ones? |
Don't mind the help page - good idea - but users who want to get going don't read - they want instant clearness. A plain [+] has a disadvantage. What about this dialog when the [+] is pressed? Your point about which file to run or which directory to use for new is only partially valid. The left hand side tree typically has an active selection, and also the right hand-side file tabs has an active file. |
Hope I don't offend you or make you unhappy with all my issues - I love the tool and its clean design! |
Did you see the new help button? |
Regarding your suggested "New file" dialog. The "browse" function behind "Enter directory name" would have to duplicate much of the file tree functionality. This is a) a lot of work for something that already exists and b) I am generally not a fan of duplicate functionality. Why would one want to have multiple ways to achieve the same thing? If there's a need for a "better" way to do something then we need to ask if the old way of doing it should be removed entirely. Should it? Is the "new" context menu to difficult to use? Would your "new file" dialog incl. the browse widget be easier to use? |
I understand the doubleness argument and don't like duplication either. It happens a lot by the way because different users have different styles of working, different expertise level and different knowledge of the tool. Think of how you can do feature in eg MSWord: app menu, button bar, hotkey, right click entry). The crux of this ticket is about features not being clearly visible, and suggesting making them visible to help (novice) user. The "new" feature being one of the most important ones. I suggested adding it to the "banner" page as a floating button and to a button bar. You explained that it was hard because "new" had sub-features (target directory, example), so I showed a possible dialog. I personally like the button bar - I think it is a very clear indication of the core features for (novice) users. My dialog "repairs" the problem of the sub-features. I would not eliminate the current way of right clicking and doing new, that also has benefits. In the end it is just a choice of what kind of users you want to address primarily - and the amount of coding for you :-( The new "help" button is ok - but only for users who read - not for the impatient ones. It's your project - your decision - keep up the good work 🥇 - don't be distracted by my comments from the side line! |
When I first opened the app (using LEGO), I discarded it because I missed the key features.
That was due to three reasons
May I suggest
For example
The text was updated successfully, but these errors were encountered: