On online collaboration and our obligations as makers of software An Essay by Baldur Bjarnason www.baldurbjarnason.com Is it the notetaking system that’s helping you think more clearly? Or is it the act of writing that forces you to clarify your thoughts? Is it the complex interlinked web of notes that helps you get new ideas? Or is it all the reading you’re doing to fill that notetaking app bucket? Is all of this notetaking work making you smarter? Or is it just indirectly forcing you into deliberate, goalless practice? Towards a crap decisionSo much knowledge not being applied notetakingbloggingsoftwarethinkingcommonplace
What do I need to read to be great at CSS? An Article by Baldur Bjarnason www.baldurbjarnason.com A rule of thumb is that the importance of a blog in your feed reader is inversely proportional to their posting cadence. Prioritise the blogs that post only once a month or every couple of weeks over those that post every day or multiple times a day...Building up a large library of sporadically updated blogs is much more useful and much easier to keep up with than trying to keep up with a handful of aggregation sites every day. bloggingcsscodelearningrss
136 things every web developer should know before they burn out and turn to landscape painting or nude modelling An Article by Baldur Bjarnason www.baldurbjarnason.com The best way to improve software UX is regular direct observation, by everybody on the team, of the work done. Have some personality. Minimalism is garbage. Metaphors are fantastic. Naming things is fantastic. Try to write HTML that would make sense and be usable without the CSS. The buyer is quite often wrong. That fact never changes their mind. Working on a functioning app’s codebase does more to increase its quality than adding features. A good manager will debate you, and that’s awesome. The term ‘project’ is a poor metaphor for the horticultural activity that is software development. Two Hundred Fifty Things an Architect Should Know wwwworkuxcollections
Nobody gives a hoot about groupthink An Article by Baldur Bjarnason www.baldurbjarnason.com Two relatively common ‘fashions’ today are real-time collaboration and shared data repositories of one kind or another. Both increase productivity in the naive sense. We work more; everybody is more active; the group feels more cohesive. The downside is that they also both tend to reduce the quality of the work and increase busywork. On that of the highest authorityPersonal Information Management (PIM) productivitycollaborationinformation
Beyond Artboards An Essay by Chuánqí Sun medium.com The Pursuit of Lossless Design-Development Handoffs. Can't developers just see?We are the ones who paved the pathUntil we get there processinterfacesdesign
Can't developers just see? We designers love artboards. From rough UI sketches to high fidelity mockups, we see ourselves as visual artists expressing ideas on artboards that have a pre-defined width and height. To start a new project, we declare the size of the artboard in the first step. What about responsive design? Not a problem! We diligently design on three artboards — one for mobile, one for tablet, and one for desktop — with content elegantly adapting, scaling, reflowing, reordering, and reprioritizing. We proudly hand off the artboards to developers while patting ourselves on the back: this is how responsive design should be done. After weeks of arduous engineering, the product finally comes out. We find, to our great dismay, that some copy is hanging off the grid, the focal point of the hero image has been cropped out, the font sizes don’t even come close to the type ramp. What went wrong? Can’t the developers just see everything on all those artboards? Nope. Start drawing, then put the box around it
We are the ones who paved the path No matter how many screen sizes our artboards account for, some user’s browser will break loose from our prescription. With users resizing, rotating, and zooming the screen, new devices stretching, squashing, curving, and cutting (e.g. the speaker area in iPhone X) the screen, the sizes become infinite. Good luck making an artboard for each one of them. Artboards are a lossy format. Using artboards in a handoff is a lossy process. When we pitch a finite number of plans against an infinite number of situations. We inevitably get in-betweens. Once there are in-betweens, there are unknowns. Once there are unknowns there is guesswork. Once there is guesswork, there are surprises. Engineers take the path of least resistance. We are ones who paved the path. gridless.designChanging Our Development Mindset
Until we get there As a designer, learn writing HTML, or better still, semantic HTML. If coding up the entire design is too hard, try coding up one component at a time, and not worrying about CSS. The HTML alone will prove invaluable for developers to understand the content structure. In addition, you are forced to optimize the information architecture as you work out the code from content. If coding by yourself is out of the question, pair up with the engineer who will receive the design. Work closely with him or her to prototype the design, validate responsive behaviors, and obtain feedback on the feasibility. Don’t call it an iteration until the design has seen played with in code. As a manager for large enterprise, co-locate your designers and developers, encourage interdisciplinary learning, understand that each minute spent on coding before the handoff translates to ten minutes saved from changing and fixing issues after the handoff. As a stakeholder in the handoff meeting, give the designer a thumbs-up when he or she demos live code running in browsers in place of mockups on artboards. That’s a design champion you are looking at. html