Tag Archive / front-end

• The Void

  These days, I have to use the term “app bulders” instead of “front-end developers” because most front-end developers aren’t working on the front-end anymore.

  One result is that I’m not part of any dev community. These days, I stay with the following communities:

  • UX
  • Information Architecture (IA) or
  • Accessibility

  because they have something of value that I can use across any tech stack.

  The thing I worry about is that developers like me are a) being pushed to non-coding/programming roles or b) pushed out of tech altogether.

  @iwilsonjr (8:09 AM · Mar 7, 2021) – https://twitter.com/iwilsonjr/status/1369817620741033984

• The Last Five Years

  A response I gave to Heydon Pickering‏ (@heydonworks) on Twitter:

  I think about this as "Engineering is about solving problems. Design is about solving the right problems."

  @iwilsonjr (2:24 PM · Dec 12, 2018) – https://twitter.com/iwilsonjr/status/1072935333329887233

• The State of Front-End Development in 2017 (…well, at least, my version of it…)

  A response I gave to Roger Johansson‏ (@rogerjohansson) on Twitter (please read through the whole thread):

  From my view, it seems that front-end development has split into two camps: one web-focused, one app-focused.

  @iwilsonjr (6:20 PM · Jul 8, 2017) – https://twitter.com/iwilsonjr/status/883812973730570244

• A Brief Note on Container Queries and RWD

  Well, while making the first steps in writing my next lecture about responsive design, I came upon a Tweeter discussion last week. Ethan Marcotte, author/mastermind behind RWD, talked about container queries and his support for them. Very interesting read.

  Ethan Marcotte “On container queries.”

  I’ve heard about container queries before during the last year or two. But I decided to read this article with much more intent because of topic relevance.

  To describe container queries, you need to think about web apps/sites as a system. Changes via media queries are macro, that is, applied to the whole system. It’s what we been doing for years. We build the base (preferable mobile first but any sort of initial state we want) and apply changes at certain breakpoints. So when we write the following media queries:

  @media (global conditions/breakpoints #1) {

  … some changes here...

  }

  @media (global conditions/breakpoints #2) {

  … some changes here...

  }

  etc..

  what we are doing is

  

  Even though these changes are to certain areas such as footer/header/etc.., these are applied as if the whole app is one big container.

  But with container queries, we are applying changes at the micro level. Instead of the previous example, we are applying changes to local containers. The queries will be influenced by the container conditions, not by the overall viewport. So now instead of the previous model, we have the following:

  

  and with each part

  

  we are applying changes on the local level/containers. These media queries are not global and [could] be different from other containers. You could have a combination of global and local conditions in this system as well (don’t know if this would happen but you never know):

  

  As for the talk/lecture, nothing had really changed. The main focus of the talk is the “why’s” of what we do in terms of RWD. However, it is obviously something to think about further.

• Revisiting The Art of Responsive Design

  The Art of Responsive Design

  About a year ago, I wrote a blog post about responsive design. But instead of the usual techniques, I decided to describe it with three terms – Constraints, Content, and Context.

  A year later, these three terms are more relevant than ever, especially Context. I am thinking about re-editing the post for brevity but the main points will remain.

• The Content Problem

  When did it become acceptable to deny content, based on certain criteria, because it was inconvenient?

• Coding The Problem

  There is this “thing” that has been nagging me for almost a year.

  Basically, it’s a conversion that I had with a CEO of a company. Anyways, during the course of the conversation, he brings out this remark:

  “Your job is to code, just like the designer’s job is to design.”

  That comment bothered me. It wasn’t a comment bore of malice or ignorance. It had some truth to it. But it missed an important point. It was the equivalent of saying “My job is to write HTML.”

  Now, there’s nothing bad; that is part of my job. But only a part.

  No, my annoyance is this:

  If my job was just coding, then I’m not doing a good enough job.

  OK. Let me explain.

  Coding is (relatively) easy. Businesses can pick and choose what company or freelancers to do the work. For a cheap price, the work can be farmed out to anyone of the many off-shore companies at will.

  Altogether, that the big talent pool of coding talent.

  You, (client/CEO) have to go through this massive pool to find the right person. But that is not what you are looking for. The truth is that you are not looking for someone to code.

  You need someone to solve your problem.

  As for coding? It’s a means to an end. Employers don’t hire people who code; they hire people who can solve their problems. (And also it’s the same thing that will keep them around…)

  Now, I wish he was around when I said this. I have no doubt that both of us would be agreement.

  There was another thing that he said, in jest, but in hindsight just as important. Basically, people like myself like the “shiny, new projects”. And yes, I admit, they are the nice ones to work on.

  But. There is a group of problems, the “old – fixed it just for now” problems that really need attention. The ones that are begging for someone to just look at and say “you know, if you give me some time, I think I could make this better.”

  There are lots of those problems that need serious attention, not the million dollar, new app of the month ones.

  Then, there is The Content Problem.