- Posted in development javascript svelte
I made some screencasts showing how to implement components in Svelte.
I am working on a UI framework/method to rapidly prototype interfaces. As I build it I thought I would strategically record certain parts so our team and others can learn alongside with me.
We built Bedrock before which we use daily and is super powerful, but has its downsides. But that is food for another blogpost.
- Posted in css development javascript npm react - 1 comment
Is a package like classnames “overengineered”? I stated on Twitter that a package called classnames felt overengineered to me. I based myself on the npm page where this code example is given:
var btnClass = classNames('btn', this.props.className, {'btn-pressed': this.state.isPressed,'btn-over': !this.state.isPressed && this.state.isHovered});
The first reason I felt this was overengineered was because this kind of code actually belongs in CSS:
.btn:hover {/* Styles */}.btn:active { /* Styles */ }.btn-pressed { /* Used as .active I presume */ }
I understand why giving something a class conditionally might be handy, but do you really want people to figure out that a button should have a class of btn-overwhen the state is not pressed but hovered?
And then have that match up to another logic on the CSS side?
Bramus and Sebastian rebutted that it’s actually a very handy utility. So I am sure there are situations I am not aware of where it might be handy.
At the moment I feel like it’s only invented because of a deeper problem: trying to write CSS in Javascript.
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!
- Posted in accessibility
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.
- Posted in svelte - 1 comment
I might start writing some blog posts to keep up with learning Svelte. I wrote this one, more might follow, but I am not promising anything ;).
The first topic of today is :class.
Take a look at this code, we add a class of .blue when foo is true:
<script>
var foo = true;
</script>
<style>
.blue { color: blue; }
</style>
<h1 class="blue {foo ? 'foo': ''}">Hello world</h1>This code works but it’s not very Svelte-ish.
In Svelte you can dynamically add a class based on, for example, whether a Javascript variable is true or false.
For example
<script>
var foo = true;
</script>
<style>
.red { color: red; }
</style>
<h1 class:red="{foo}">Hello world</h1>Now, you can also combine a regular class with an “optional class”:
<script>
var foo = true;
</script>
<style>
.red { color: red; }
.blue { color: blue; }
</style>
<h1 class="blue" class:red={foo}>Hello world</h1>Here is a real life example of this in practice:
In App.svelte:
<script>
import Button from './Button.svelte';
</script>
<Button>Hey</Button>
<Button variant="primary">Hey</Button>
<Button variant="success">Hey</Button>In Button.svelte:
<script>
export let variant = null;
</script>
<style>
.button { padding: 0.5rem; }
.primary { background: #748DD5; border-color: #748DD5; color: #FFF; }
.success { background: #75D37E; border-color: #75D37E; color: #FFF; }
</style>
<button
class="button"
class:primary={variant==='primary'}
class:success={variant==='success'}
>
<slot></slot>
</button>See this REPL for an example.
- Posted in Uncategorized
Jason Fried writes, in the foreword to Shape Up:
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.
- Posted in Uncategorized - 2 comments
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:
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.
Wie heeft er aanraders?
- Posted in Uncategorized - 1 comment
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.
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:
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.
- Posted in accessibility belgische-problemen public-transport
Ik postte er net een draadje over op Twitter.
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.
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.
Ondertussen beschouwt de NMBS in haar vervoersplan externe bronnen om aan reizigersinformatie te geraken als “concurrentie” (Slide 16 – Vervoersplan NMBS Provincie Antwerpen).
Hoe komt het dat een website uit 2010 objectief beter is dan een website uit 2019?
Hoe krijg je dat uitgelegd?