Be nice. Or else.
San Francisco, CA Designer at LoungeBuddy Joined about 3 years ago
Fair enough. I think the main issue with the touch bar is that it makes so much sense for non-pro users (those who don't know that keyboard commands and shortcuts even exist), but it was introduced on a "pro" machine.
My point about the sizing is that in one app it might be 33%, but in another it could be 20% or 50%. Sure this might work for the left-most action in all apps, but for the rest you will have to looks down regardless. That is, unless you have an impeccable memory :P
The one concern I've seen come up again and again, and something I myself experience, is that you have to take your eyes off the screen to look at it before using it, unlike shortcuts on the keyboard where you only use muscle memory. To make matters worse, the buttons are tiny and require a good degree of precision to hit.
Your solution work because there are three options in each, but what happens when the system is showing more than three optiions? I assume they would scale like Safari tabs until there isn’t any more space (the size they are currently) and the user will still have to scroll/interact to see more options.
With that said, I’m surprised the larger buttons shown in your mocks aren't the default behavior, but I don’t think that will help with the issue you are describing. You don't have to look @ a keyboards because they are always fixed. But if you are switching apps all the time, your context changes as well. In one app the same button will be a tab switcher for a website, and in another that same tap area will create new message. No matter what, the user has to look down to see what that section of the tab bar is doing, regardless of the size of the UI.
The only app I know of that "smooths out shaky line-work" is Procreate. You can customize that setting on a per-brush basis. Not sure how that would work for wireframes though…
Personally I use Notes (and the digital ruler) for wireframes, OneNote for handwritten notes, and Linea for sketches.
If you working with very specific text elements (i.e. won't change), try converting it into an outline. Not ideal, but could help with alignment.
We use Github heavily, so all of the descriptions are stored in issues that we can reference later. We also try to create action items for each section of a description (i.e. the questions I mentioned earlier) using tasks
- [ ] ……… that help to summarize what we expect to see once the PR is submitted. This way everyone is on the same page about what's been completed, and what's still WIP.
In terms of assigning people, Github handles that as well. You can assign the appropriate person/team to a particular issue, and so the right stakeholders are notified about the project. We also have tags that describe the status (i.e. In Progress, More Info Needed…, Priority Levels, etc).
Whenever I write the project brief for a developer, I try to write these sorts of flows in the form of a question. For example:
What happens when the user "does this"? (replacing
does this with the action)
When should X end?
Who will see this screen?
Since a lot of these "if this, then what" flows are based on questions, I always find that it's easier to communicate the question we are trying to answer with the intended result/action. Having the issue to refer to, and speaking with engineering in person is always the best way to go if your team/organization supports that kind of back-and-forth.
Hope this helps!
Sadly that's part of the problem. When you "Detach from Symbol", the nested overrides don't stick and the symbol reverts to whatever is on the symbol's artboard instead of using the select overrides. Thanks though – I think the solution is (sadly) to duplicate the symbol and make the edits on the new Symbol.
Funny enough, I thought Sketch aligned to the largest object this whole time. I never had any issues aligning things before this update, but now things seem to jump around. I don't like that Sketch is now dictating the order of my layers, esp. when you export to prototyping apps, where layer order and grouping matters a lot.
Another point, during the concept and development stage, I pay little to no attention to layer order, because you are trying to move quickly. This is precisely the point where you would use quick tools like the alignment bar to make quick adjustments. That workflow is now forces you to change your behavior instead of working with you.
I'm all for opinionated design, but if it isn't already, this should be a setting not the default and only behavior.
Be nice. Or else.
Designer News is a large, global community of people working or interested in design and technology.