User interface discussion
tonyarnold opened this issue · 13 comments
I hope you don't mind, @pdcgomes but I'd love to start a bit of a conversation about what the UI for XCActionBar might look like.
Initial thoughts are that matching Xcode's Open Quickly makes a lot of sense:
There might need to be a small settings icon somewhere on the panel, for the eventual customisable hotkeys and other prefs.
Thoughts, ideas, suggestions? I realise it's early days, but I'd like to contribute and building out a nice UI like this is probably a couple of hours once there's agreement on what should be done.
/cc @orta
I'm also a big fan of the UI of LaunchBar 6 if we wanted to go for a chunkier, less Xcodey look:
No not at all, I think it's great that people are showing so much enthusiasm!
I'd say that ultimately making it look like Open Quickly is probably the way to go if the feature set remains similar, i.e., there's no hierarchical navigation of any sort and you're only allow to select an item from the list.
Having that said, I do have some ideas for actions for which the user can specify additional input, and also cases where the user "collect" things (blocks of text for example) and operate on them in bulk, meaning something a bit more flexible would be needed.
I'm also thinking of adding a "scoped" search where the user can type a prefix like s: or d:, etc. to narrow down search results to certain domains (for example s: would only search code snippets, d: would only operate on the debug console, etc.) a bit like Dash does. This would probably rely on having the typed prefix transform into a custom TokenField or something similar.
I'm personally a big fan of Alfred and have it setup like this:
As you can see, the settings icon (which is can actually be turned off) fits quite nicely (CMD+, works as expected too).
Just throwing my immediate thoughts out there so you have a rough idea of where I'm planning on taking this.
Given that there are a few types of actions at the minute, the open quickly-like would feel quite good ( you may even be able to outright re-use the classes too, negating the need for building UI )
Then there could be custom icons for
- Menu Actions
- Built in actions
- Custom actions
- Code snippets
Repurposing the Open Quickly classes for UI and interfaces for data providing and string matching would definitely reduce the code base and it's something to look at for sure.
But given future plans, it would probably not quite serve the purpose, so I'm happy to keep a separate UI implementation for it - also makes the whole thing a bit less dependent on Xcode internals (granted this is a plugin, but still...).
To make it look like Open Quickly we'd need:
- Similar chrome (rounded window surrounding the text input area)
- Tweak input field so that font size matches
- Add "Clear" button to input field
- No floating space between input field and results table
- Results table expands/shrinks with results (up to fixed maximum)
- Results table animates while expanding/shrinking
- Tweak results cells so they match Open Quickly's
- Come up with icons to represent the different kinds of actions (Font Awesome probably has some good enough placeholder assets we can use)
Think your reasoning is totally cool, can help with assets too if needed
I just saw this from Dave Verwer's newsletter and I already fell in love with it; kinds of feels the spot that CodePilot left.
My 2 cents in the UI talk I think going for the Open Quickly look & feel would work beautifully for the actions at hand and it can grow "easily".
If needed help I can contribute to the project with some of my ⌛ can't help with assets because I suck at 🎨 though
OK, great! I'll try to squeeze in a little work on a PR for this tomorrow night when the kids are asleep. It sounds like going for a look consistent with "Open Quickly" is the logical choice, so I'll concentrate on that first 😄
@esttorhe I won't have a massive amounts of time over the next few weeks but I'll try to bring some bring some structure and create a few issues/milestones based on some of the ideas that I've got right now. Based on that we can see how people could best contribute in a way that makes sense!
Either way, at this stage I'd say that the most relevant aspect is to gather feedback and ensure the foundation is rock solid and can be built upon with confidence.
A settings panel ( for things like the keyboard shortcut ) could be done using my Preferences plugin. I made it with this kind of thing in mind.
Sorry, took me a while to get to this.
I've checked your plugin, and it could make sense - especially if we could get other people to integrate it with their own plugins.
On the other hand...
I sort of like the approach of fully separating the settings into a separate process (Alfred and a few other apps do it), so I might just go with that approach - it'll also make up for a lighter and stabler plugin, I can simply rely on XPC or some other mechanism to pass data back and forth and can develop and test the settings app independently (which is always my preferred way).
I probably won't get to this until next week or so, so I'll give it some more thought.
Fair, I know this is a bit of an odd request, but I'd love to see this work go into a generic "XCOpenQuicklyWindow" pod. I'm currently replicating this kind of thing in another app.
I can make it a library or modular code, @orta, sure!
</semantics>
Hahaha 🙉 🙊 🙈