Tags: tools

83

sparkline

Friday, December 8th, 2017

The world is not a desktop

This 1993 article by Mark Weiser is relevant to our world today.

Take intelligent agents. The idea, as near as I can tell, is that the ideal computer should be like a human being, only more obedient. Anything so insidiously appealing should immediately give pause. Why should a computer be anything like a human being? Are airplanes like birds, typewriters like pens, alphabets like mouths, cars like horses? Are human interactions so free of trouble, misunderstanding, and ambiguity that they represent a desirable computer interface goal? Further, it takes a lot of time and attention to build and maintain a smoothly running team of people, even a pair of people. A computer I need to talk to, give commands to, or have a relationship with (much less be intimate with), is a computer that is too much the center of attention.

Thursday, November 16th, 2017

The Burden of Precision | Daniel T. Eden, Designer

I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.

With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.

Tuesday, October 3rd, 2017

CSS Grid PlayGround | Mozilla

A ten-part tutorial on CSS Grid from Mozilla.

Monday, October 2nd, 2017

Essential Image Optimization

Following on from Amber’s introduction, here’s a really in-depth look at image formats, compression and optimisation techniques from Addy.

This is a really nicely put together little web book released under a Creative Commons licence.

Wednesday, September 27th, 2017

5 things CSS developers wish they knew before they started | CSS-Tricks

  1. Don’t underestimate CSS
  2. Share and participate
  3. Pick the right tools
  4. Get to know the browser
  5. Learn to write maintainable CSS

Thursday, September 7th, 2017

The Uncomfortable - a collection of deliberately inconvenient objects

These are ingenious. I think the chain fork is my favourite, but the uncomfortable broom is pretty great too.

Then there’s the inflatable doorknob.

Tuesday, August 29th, 2017

User Interfaces for Variable Fonts · An A List Apart Article

A good introduction to variable fonts, and an exploration of the possible interface elements we might use to choose our settings: toggles? knobs? sliders? control pads?

Software development 450 words per minute - Vincit

Tuukka Ojala is a programmer working on the web. He’s also blind. Here are the tools of his trade.

Tuesday, July 11th, 2017

It’s Time to Make Code More Tinker-Friendly | WIRED

We don’t want the field to de-­democratize and become the province solely of those who can slog through a computer science degree.

So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.

Wednesday, May 24th, 2017

A workshop on evaluating technology

After hacking away at Indie Web Camp Düsseldorf, I stuck around for Beyond Tellerrand. I ended up giving a talk, stepping in for Ellen. I was a poor substitute, but I hope I entertained the lovely audience for 45 minutes.

After Beyond Tellerrand, I got on a train to Nuremberg …along with a dozen of my peers who were also at the event.

All aboard the Indie Web Train from Düsseldorf to Nürnberg. Indie Web Train.

I arrived right in the middle of Web Week Nürnberg. Among the many events going on was a workshop that Joschi arranged for me to run called Evaluating Technology. The workshop version of my Beyond Tellerrand talk, basically.

This was an evolution of a workshop I ran a while back. I have to admit, I was a bit nervous going into this. I had no tangible material prepared; no slides, no handouts, nothing. Instead the workshop is a collaborative affair. In order for it to work, the attendees needed to jump in and co-create it with me. Luckily for me, I had a fantastic and enthusiastic group of people at my workshop.

Evaluating Technology

We began with a complete braindump. “Name some tools and technologies,” I said. “Just shout ‘em out.” Shout ‘em out, they did. I struggled to keep up just writing down everything they said. This was great!

Evaluating Technology

The next step was supposed to be dot-voting on which technologies to cover, but there were so many of them, we introduced an intermediate step: grouping the technologies together.

Evaluating Technology Evaluating Technology

Once the technologies were grouped into categories like build tools, browser APIs, methodologies etc., we voted on which categories to cover, only then diving deeper into specific technologies.

I proposed a number of questions to ask of each technology we covered. First of all, who benefits from the technology? Is it a tool for designers and developers, or is it a tool for the end user? Build tools, task runners, version control systems, text editors, transpilers, and pattern libraries all fall into the first category—they make life easier for the people making websites. Browser features generally fall into the second category—they improve the experience for the end user.

Looking at user-facing technologies, we asked: how well do they fail? In other words, can you add this technology as an extra layer of enhancement on top of what you’re building or do you have to make it a foundational layer that’s potentially a single point of failure?

For both classes of technologies, we asked the question: what are the assumptions? What fundamental philosophy has been baked into the technology?

Evaluating Technology Evaluating Technology

Now, the point of this workshop is not for me to answer those questions. I have a limited range of experience with the huge amount of web technologies out there. But collectively all of us attending the workshop will have a good range of experience and knowledge.

Interesting then that the technologies people voted for were:

  • service workers,
  • progressive web apps,
  • AMP,
  • web components,
  • pattern libraries and design systems.

Those are topics I actually do have some experience with. Lots of the attendees had heard of these things, they were really interested in finding out more about them, but they hadn’t necessarily used them yet.

And so I ended up doing a lot of the talking …which wasn’t the plan at all! That was just the way things worked out. I was more than happy to share my opinions on those topics, but it was of a shame that I ended up monopolising the discussion. I felt for everyone having to listen to me ramble on.

Still, by the end of the day we had covered quite a few topics. Better yet, we had a good framework for categorising and evaluating web technologies. The specific technologies we covered were interesting enough, but the general approach provided the lasting value.

All in all, a great day with a great group of people.

Evaluating Technology

I’m already looking forward to running this workshop again. If you think it would be valuable for your company, get in touch.

Tuesday, May 23rd, 2017

Evaluating Technology – Jeremy Keith – btconfDUS2017 on Vimeo

I wasn’t supposed to speak at this year’s Beyond Tellerrand conference, but alas, Ellen wasn’t able to make it so I stepped in and gave my talk on evaluating technology.

Evaluating Technology – Jeremy Keith – btconfDUS2017

Monday, May 22nd, 2017

Are we making the web too complicated? | Seldo.Com Blog

Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:

Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.

I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:

Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.

I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.

But we can all agree that the web is a wonderful thing:

Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.

Thursday, April 27th, 2017

Using NPM as a Build Tool | gablaxian.com

For a small to medium sized project, this sounds like a sensible way to approach build tasks. It feels nice and close to the metal.

Wednesday, April 26th, 2017

Painting with Code : Airbnb Design

Very clever stuff here from Jon in the tradition of Bret Victor—alter Sketch files by directly manipulating code (React, in this case).

I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.

Thursday, April 13th, 2017

The Setup - Jeremy Keith · Hey!

As part of an ongoing series where we ask industry professionals what they use to get the job done, we speak to Jeremy, technical director at Clearleft.

I couldn’t resist the smartarse answer about my “dream setup.”

Thursday, March 23rd, 2017

Modern JavaScript for Ancient Web Developers

Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:

The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.

Wednesday, March 22nd, 2017

sketch-to-fractal-comp on Vimeo

Everyone in the Fractal Slack channel is currently freaking out about this. Veeeeery iiiiinteresting!

sketch-to-fractal-comp

Friday, March 17th, 2017

Should you learn [insert shiny new tool]? | Zell Liew

This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:

  1. Figure out what [insert tool] does.
  2. Figure out what sucks right now
  3. Determine if it’s worth the investment
  4. Learn it (if it’s worth it)
  5. Differentiate opinions from facts

Most of the examples he gives are tools used before deployment—I have a feeling that different criteria should apply when weighing up technologies written directly in user-facing code (HTML, CSS, and JavaScript).

Tuesday, February 21st, 2017

The Five-Tool Designer » Mike Industries

Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):

  1. Visual Design & Animation
  2. Interaction Design
  3. Getting Things Done
  4. Teamwork
  5. Leadership

Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.

Sunday, February 19th, 2017

On Design Tools and Processes | Viljami Salminen

Changing our ways of thinking and doing isn’t easy. Sometimes it’s necessary though, and the first step on this journey is to let go. Let go of our imagi­nary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.