The shortcut to run the last plugin in Figma is ⌥ ⌘ + P.
Alternatively you can use ⌘+/to bring up the global command menu and type the name of the plugin.
You can also set up a custom shortcut in MacOS’s Shortcuts panel based on the plugin name. I didn’t do this yet in the screenshot below, but you if you use the exact menu item name, it should work.
What I did however was set up shortcuts for Pack Horizontal and Pack Vertical. I use these commands all the time to quickly build designs.
Interested in learning to work with Figma in a better way? I organise Figma workshops with Mono, the company I founded and work for. You can read more info here. Sign up to the newsletter if you want to be the first to know when we announce dates for new public workshops. Spaces are limited!
Zoals zo vaak wordt een blog post getriggerd door een tweet. En een tweet door een gedachte.
Roel, die ik persoonlijk al vele jaren ken, vertelde ons een paar weken geleden in een professionele context (een excellente audit door zijn bedrijf 11ways) dat het opletten is als je tekst in uppercase zet in je interfaces.
Het zou dan wel eens kunnen dat een schermlezer het als een afkorting beschouwt. Ik ben sowieso niet echt fan van uppercase tekst, maar als decoratief element in een kort tekstje kan het vormgeeflijk soms wel voor mij.
Maar dan heb je dus het risico dat een schermlezer een TAGNAME uitleest als T-A-G-N-A-M-E en dus alle letters apart leest, alsof TAGNAME een afkorting is. Hetzelfde geldt voor exotische ASCII karakters, maar daar is het nog erger: dan krijg je als je een schermlezer gebruikt gewoon een hoop onverstaanbare karakters te horen. Het zou zelfs gelden voor tekst die met CSS uppercase gemaakt wordt ( text-transform: uppercase).
Nu, persoonlijk denk ik dan ergens dat de makers van schermlezers hun software moeten fixen – dat als in de broncode geen caps staan dat ze het dan ook niet uitlezen. Maar zolang een populaire schermlezer die fout bevat, is het wellicht beter om niet te veel tekst in caps te zetten. Wat op zich weer een goede vormgeeflijke tip is.
Over the last few years, there’s been a heightened curiosity about how we work at Basecamp. People often ask us how we get so much done so quickly at such a high level of quality with such a small team. And how we keep our teams together for years and years.
I got a bit irritated by this, and the style of Basecamp’s communication in general. They’re always putting themselves on this pedestal of “we are so awesome”, when in reality their application is severely lagging behind the competition.
When they invent something it’s always the next best thing. I wrote about some of my frustrations with Basecamp before. When I initially read this statement I channeled my thoughts into some tweets which now formed the basis of this blog post.
I am increasing irritated by Basecamp’s communication strategy. I feel like you can’t play the underdog for 15 years. We’ve been a Basecamp customer for a while and over time I saw the product mostly get worse instead of better.
Last year we dumped $900 in the bucket for a year’s subscription to Basecamp but then, Notion happened, and we just moved on to software that is essentially just better. I haven’t touched our Basecamp account for months.
I used to be a big Basecamp believer for a very long time, but the product is stagnant and totally being disrupted. I am writing this blog post in Notion’s editor that is quite awesome, works with markdown, in an app that is lightning fast, that we use to manage our company.
Basecamp is stuck in a reality of 10 years ago and happily chugs on writing blog posts about how they struggled to implement a grouped list within their self-imposed limits.
I just wonder, how long can you hold on to a set of beliefs that is just no longer true? Basecamp is using the same marketing techniques as they did 13 years ago. I read “Getting real” in 2006. Since they formed 37signals have condensed their internal beliefs into content marketing.
I’ve been a big believer and have championed the company as one of my favorite companies in the past. But I’ve grown increasingly frustrated with them banging the same drum. Having access to the kind of resources that Basecamp has you just can’t keep playing the underdog.
I believed their statements about product design when the product was evolving, but over the years they’ve focussed on things I don’t care about (hill chart anyone? The weak chat within Basecamp?), didn’t evolve on what they claim is super important (speed), and even did poorly when it came to basic UI (oh that breadcrumb UI).
Over time, the product got more expensive while the overall experience got worse. The editor is still the same lightweight thing that doesn’t meet my needs. Integrations are nonexistent. The app ignores the 2019 fact that you are also using other apps. Ever tried linking a Google doc to Basecamp? Welcome to the past. Basecamp 3 feels like an app from 2012, not 2019.
I don’t care how many people it takes to build a better product. I don’t really care that they make their feature sprints 6 weeks. What I want is the better product. Not an explanation of how they were “so lean” and only have 1/2 the feature.
Ik dacht — met een vakantie die er aan komt — misschien moet ik nog eens een boek lezen?
Ik heb al wat non-fictie op een lijstje staan:
Gigantisme – Geert Noels
Click here to kill everybody – Bruce Scheiner
Waarom de wereld niet naar de knoppen gaat – Maarten Boudry
Misschien moet daar wel iets van fictie bij? Ik vond Normal People van Sally Rooney wel OK.
De laatste jaren heb ik soms een poging gedaan om iets van sci-fi te lezen (dingen van Ann Leckie of Neal Stephenson) maar ik geraak daar dus helemaal niet door. Geef mij dus maar iets dat zich afspeelt in de echte wereld.
Ken je dat, van die drukke periodes waar je agenda jou leeft, en je eigenlijk geen tijd hebt? Geen stukje rust? Van het ene naar het andere? Wel, zo een periode gaat nu eindelijk eindigen, binnen een een dikke week denk ik.
Binnenkort dus: genieten van het niets. En na even vakantie toch weer uitkijken naar werk, denk ik.
Ik ben er nu voor aan het zorgen dat elk project afgewerkt is, zodat ik kan beginnen van een leeg blad.
Het wordt een spannend werkjaar denk ik. Het werkjaar waarin Mono 5 jaar oud wordt. Waarin we onze groei kunnen voortzetten en ons bedrijf kunnen vastklikken als een blijver.
This is some extended writing that got kickstarted by watching Brad Frost’s talk about Design Systems at the recent CSS Day 2019. If you are interested the video is online.
Brad Frost at CSS Day 2019
Before the conference I had heard a podcast episode where Brad was talking about design vs. dev and design systems with Dan Mall recently and I was like: Brad Frost certainly has veeeeery similar ideas about design systems as I have.
And then the presentation came and for the most part I was just nodding and I as like: yep, yep, that’s what we are doing in our projects. Brad uses his Pattern Lab, we use Bedrock. The deliverable to clients is a set of HTML/CSS templates and documentation of the components and patterns used. The underlying ideas are similar.
Now at some point Brad talked about how it might be interesting to keep the design system in basic HTML (as opposed to doing it directly in a framework like React) because, well, it can be a bit more stable, since HTML and CSS do not change every few years like Javascript frameworks do.
I am not sure I agree. On a surface level I tend to agree because I am not a JS developer and that part of the system, the HTML/CSS, is exactly what I can manage. But isn’t this a choice that is just limited by “our own skillset”? I.e. Brad Frost has wrote a blog post on his struggle to learn React.
I am in the same boat. I simply have never had the time (nor interest I guess) to learn React properly. I am simply not a JS developer and learning React is pretty much learning all the latest JS techniques.
My work is design, I live in a design application, sometimes in code, but never in deep application code. I don’t need to “make a route”, I just create a new template. If I want to insert a library, I don’t need go through a lot of magic mumbo jumbo, I just use a script tag.
Now, I’ve been doing a lot of thinking over the past two years. The thinking always comes down to the same: whether we should maybe start thinking of moving our design systems deliverable to something like React or Vue when delivering them to our clients – instead of basic HTML and CSS.
Do we deliver basic HTML and CSS because:
we don’t specifically have the React/Vue skills
because it is leaner – less work to make our “design point”
because we don’t want to bother with the JS flavor of the day? (our clients can literally use any programming language)
And if we deliver a big HTML/CSS kit, how much translation work is there for the devs to make it a real working UI framework/design system?
If we would do a React deliverable, would the dev parties we work with even like that? The people I have interviewed about our deliverable are seemingly perfectly happy with what we gave them. I’ve heard things like “A great base to continue from. ” – “I have never seen such an extensive deliverable” “now we have much less work than we anticipated” “we have little CSS skills in the team so this was a godsend” and later on “we’ve used your design system to create 3 more apps without the involvement of a designer. Awesome.”
A lot of questions to unpack and I’m not sure.
All I know is that I am a UI designer who is not fluent in React or Vue at all, but my HTML/CSS skills are there and they are up to date. And this counts for the rest of our team as well.
So should we React? I dunno. I would welcome some opinions on this from designers who did venture a bit deeper into React/Vue than I did.
Anyway. I can go on and on about the design systems topic, as it has been a big topic at work for the past 2 years. I might just have to split this off into a separate blog post.
De nieuwe NMBS website is totaal niet toegankelijk.
De website was een tijdje in een soort beta-vorm, en dan heb ik het door de vingers gezien om er over te klagen.
Maar nu is de website toch al een tijdje uit, en heeft NMBS ook besloten om mijn eigen “preferred interface” naar de treintijden nl. m.nmbs.be ( ook een tijd http://mobile.b-rail.be/nl/ ) af te sluiten.
Oubollig maar snel en toegankelijk. Geen zever.
Dus nu wordt het een persoonlijk probleem. De m.nmbs.be wordt nu geredirect naar belgianrail.be .
De basis van de toegankelijkheid werkt niet, en dan heb ik het nog niet eens getest met een schermlezer. Als je tabt van veld 1 naar veld 2 nadat je iets in veld 1 typt wordt het veld leeggemaakt. Als je nadat je een resultaat hebt op de back button van je browser klikt om terug te gaan gebeurt er… niets. Dit is de basis, en dat is niet in orde. En dat was het ervoor wel. Hoe kan iets zo hard achteruit gaan?
Toegankelijkheid is een Europese verplichting voor overheids websites. Vanaf september 2019 moeten alle nieuwe overheidswebsites toegankelijk zijn (zie deze post). Dat is dus binnen 3 maanden hé.
Om dit te bouwen worden publieke middelen gebruikt.
We krijgen een nieuwe flashy website die slechter is dan de vorige.
3/4 van de homepage wordt gevuld met reclame en “nieuws”. Hint voor de NMBS: de toptaak van de website is de treintijden opzoeken. Daar moet ik geen gebruikersonderzoek voor doen.
Er zijn nu mensen die gewoon niet aan hun treintijden geraken, tenzij ze een applicatie gebruiken als Railer, gemaakt door 1 privépersoon. Een applicatie die wél toegankelijk is.
The CSS day team already put up all the videos from CSS day on YouTube, so you can already watch all of the talks! Amazing.
1.5 Brad Frost – The technical side of Design systems
A UI inventory – when you look at what is out there. Dun
This afternoon sessions opened with Brad Frost talking about the technical side of design systems.
Brad was talking about how organisations can work on a design system using a pilot project. Organisations can sort of make an inventory of their existing apps and then decide which impending (re)design to use to pilot their first design system.
He made the important statement that a design system is not a Sketch file. A design system is a collaborative tool. He showed his work on Pattern lab which reminded me a lot about what we are doing with Bedrock.
He talked about how it might be interesting to keep the design system in basic HTML because it is technology independent.
I’ve got some extended thoughts on that which I will be talking about in a future blog post. Overall this was a great talk which mostly had me nodding in agreement.
1.8 Jared M. Spool – The UX tipping point
The day ended with Jared Spool talking about the UX maturity of organisations. This was near and dear to my heart as I have been working with different clients and I’ve been figuring out why it’s possible to do good work at one organisation whereas the same techniques do not really apply to another organisation.
I think Mr. Spool has been talking about the Disney story for quite a while and has just been repeating the same talk for quite a few times. But anyway. I guess I am at the right “career stage” now to actually make good sense of what he was talking about and apply it to the work that we do at Mono. I’ve heard from some other people that they didn’t really “get” the talk – and I think it would’ve felt the same a few years ago.
Mr. Spool talked about how UX maturity can grow within an organization. There’s the dark ages where there is no UX at all, followed by what he calls “spot UX”, where someone does something small but it is not structural.
The next phase, phase three, is UX as a service. The organisation figures out they need UX. Everyone can call up the UX team and use them as a some sort of global service.
The next phase is that the teams who need this service figure out that they want a full-time person. So things move over to embedded UX teams. Now, Jared also talked about a fifth level which he calls Infused UX design, and this is when the whole org is at a certain design level and can deliver outstanding results. This is what happened with Disney.
He argued that in big organisations different teams and different parts of the company are at different levels.
More…
More posts about CSS day are coming when I find the time!
(You might have noticed I’ve skipped over some of the talks in my report – this was because I was either not very attentive during the talk or I don’t have a lot of to say about the topic.)
I wrote so much about CSS day that I decided to split the content in multiple blog posts. I posted the intro yesterday. Now it’s time to get into the talks.
CSS day is a 2 day conference. Day one was the “UI day” with a focus on design talks, often zooming in on the intersection of design and development.
Day two was the actual CSS day with mostly technical talks about CSS itself. In this post I will cover the first four talks of the first day.
Sara Soueidan
Sara Soueidan was the M.C. for day one and opened with the intro and practical things.
My colleague Emily had visited Sara’s accessibility workshop earlier this week about accessible front-end patterns. I would have loved a talk by Sara (remembering the splendid talk about SVG filters from CSS day 2018), but unfortunately she did not present. I do have to say she did a splendid job at MCing.
1.1 Josh Clark – A.I. as your new design material
The first day opened with Josh Clark talking about “A.I. as your new design material”. He argued that we should be thinking about things like machine learning as another ingredient to add into the mix when designing.
I thought this was really interesting as an idea, but I cannot see a practical way in front of me to try and incorporate machine learning into the interfaces that we make. I am also not sure whether machine learning is really a “design ingredient”, unless you assume “the design” means “the thing”.
Josh had lots of good (and bad :)) examples to basically give the audience a chance to start thinking about how they could use machine learning.
He explained us that we have to teach the machine (well, computers — the model — you know what I mean) what is “normal” and that doing that is a challenge in itself. We need to anticipate the problems that machines will have and set the right expectations for ourselves.
Machine learning is a probabilistic tool and should be treated as such. 80% certainty and 95% certainty are 2 different things. Machines don’t think like humans. They uncover other connections. Since the machines are weird, we can sometimes draw insights from the unexpected.
He pointed to some cloud services anyone can use to experiment with machine learning – most interestingly Microsoft’s Cognitive Vision cloud services which you give a photo as input, and then it would return in text format what is on the photo (or at least sort of what is on the photo).
Josh Clark at CSS Day
I really liked the slide were David Bowie is identified as female, 29 years old by a machine. This slide is about so much in one simple looking slide.
I had already read a summary of this talk at Michel’s blog before seeing it, but it was interesting nonetheless. People obviously repeat their talks if they are a speaker, and I don’t have a problem with that.
Josh is such a skilled presenter. I was in awe about the way he juggled his slides with his words. CSS day was off to a great start.
1.2 Stéphanie Troeth – Behind the Story
Next up was Stéphanie Troeth who talked about storytelling in her presentation “Behind the Story”.
Stéphanie used to be head of research at Clearleft. She talked about story arcs, first talking about a personal story about something that happened with her at an AirBnb – then moving on to different story arcs – which was all based on some Kurt Vonnegut video.
This is curious since I had read about a talk from Erika Hall at UX London on the aforementioned UX London report that used the exact same video.
Stéphanie Troeth at CSS Day
It’s sometimes good to surface old good stuff (I think more people should know about the mother of all demo’s for instance) but maybe if I ever give a presentation I would kind of avoid showing someone else’s presentation in my presentation? I dunno. I am on the fence.
Now, her main point was that something needs to be a story to be remembered, because we humans are terrible at remembering stuff. I thought this was interesting – the point about story arcs might be useful to make some of my writing a bit more exciting – and it was well presented as well.
Then Stéphanie tried to make the connection to design and things got a bit vague in my opinion. She went on a trip down memory lane. She asked “What happened to storytelling in design?” She argued that lots of things happened between 2010 and 2013 (and a bit in 2016) but lately it is rare to find storytelling in design. She mostly referred to news articles like this one from the NY times.
My main thought, but this was also a thought I had about the talk before this was: what does this have to do with UI? There was not a lot of relationship to the main topic of the conference.
Now, I wrote down my extended thoughts on that in a separate blog post, because that opinion got way too long. So that’s something for later.
(I am going to skip over talk 3 because I honestly do not know how can I summarize it, it was like 3 talks in one talk.)
1.4 Hakim El Hattab – Building better interfaces
Let’s move on to the fourth talk of the day, by Hakim El Hattab. This was a real highlight for me. You might know Hakim as the creator of Reveal.JS. His personal website is at Hakim.se . He turned his work on Reveal.js into a product called slides.com, which is cloud software to make presentations.
Hakim el Hattab at CSS Day
Hakim’s topic was how to build better user interfaces. First Hakim walked us through some of his UI experiments which you can also see at his website. A simple example is turning a button into a loader. Your eye is already focussed on that spot, so it make sense to give feedback there.
There’s only 2 people working on that product – they are a small team and they have to make choices. So they don’t have a big design system yet. What they do have is just a UI kit. He showed us slides.com/wireframe (which is so well done) and highlighted some pretty impressive details when it comes to making UI more robust and easier to use.
He went on to talk a bit more deeply about how he handled the UI for slides.com with a deep dive into some of the UI elements they use. He told us that basically he could bring his past knowledge all together in this new product. This sounded very familiar to me. I was working on something new recently and a lot of lessons from the past came together in that UI.
He did a deep dive into UI considerations when using popovers/popouts, keyboard shortcuts, loaders etc. For me this talk was perfect because some of the things he’s shown are exactly the sort of things I feel we can still improve upon when we deliver UI to our clients.
He ended on a high note explaining his excursion into making hover dropdowns more usable in detail which was really cool (see this tweet and his presentation).
I love how he is open sourcing a lot of his work. Hakim seems like a truly great & humble guy. If you’re into UI details and animation and you can ever catch a video of this talk, you should.
More…?
More is coming up in a next blog post, probably somewhere next week!
