Hamish Taplin

Hamish Taplin

Freelance frontend developer Joined over 5 years ago via an invitation from Zach I. Hamish has invited Gareth Strange

  • 10 stories
  • Posted to Design Tools: When do we get stateful components?, in reply to Andrew C , Sep 24, 2018

    I think it depends. Are you drawing pictures of websites/apps for stakeholder approval and then handoff to devs or are you prototyping/testing/iterating more complicated apps for testing with users? If the former it's not so important.

    0 points
  • Posted to Design Tools: When do we get stateful components?, Sep 24, 2018

    I think not only state but a layout model that mimics (or is built on) the same layout model that the platform you are designing for uses. An obvious example being HTML/CSS and the box model, etc. with breakpoints.

    0 points
  • Posted to Design Tools: When do we get stateful components?, in reply to Jed Lehmann , Sep 24, 2018

    Agree 100%. I'm currently designing/prototyping a visual query-builder thing (if statements and shit) and traditional prototyping tools make anything other than high-level "do you know where to click" type tests pretty impossible.

    To really test things with users I need to write code—luckily our app is built in React and I can do so fairly easily but it still takes time and I am fortunate that my experience as a developer helps me understand the problem better and be able to prototype a real UI quickly, using state and all the great stuff React brings.

    1 point
  • Posted to Design Tools: When do we get stateful components?, in reply to Jonathan Shariat , Sep 24, 2018

    Although this sounds great and one day might be possible, the problem with abstractions is that they are often the wrong one. A great deal of assumption has to go into an abstraction and often you find out further down the line that those decisions are wrong and then change them and the abstraction becomes leaky and will eventually fall apart. It will take a huge paradigm shift, possibly involving AI or something to make this viable imo.

    Furthermore, f/e code often contains small decisions around accessibility and performance, etc that has to be decoupled from the design or it starts to restrict it (perhaps rightly in most cases?).

    I think the happy medium for now is that stuff like Framer X can possibly produce not-quite-production code (getting closer to it) so that designing, iterating and testing with users can suffer less friction. Designers can become better versed with their medium and the gap between "design" and "code" becomes smaller.

    0 points
  • Posted to Denys Loveiko Portfolio, Sep 24, 2018

    Love this. It's completely inaccessible and probably runs like crap but it's art and sometimes art pisses you off.

    0 points
  • Posted to Need some advice, starting a new stage in my life. , in reply to James Young , Aug 31, 2018

    Agree with this. Futhermore, if you're going to freelance and sell yourself as a guy who can do design/ux AND front-end then you're going to be expected to deliver great quality work in all those things. Learning as you go is going to slow you down massively (so you won't make any money) or produce sub-standard work and damage your reputation.

    Another aspect of this is that you won't find many clients who just want a static website, so you'll get dragged into using Wordpress or another CMS so you'll need to learn back-end code too, along with dealing with databases and servers and stuff which is a whole new level of pain when you're trying to get a project live.

    3 points
  • Posted to These are the logos the Trump campaign is offering the Space Force, Aug 10, 2018

    I knew Trump would be a design contest guy

    21 points
  • Posted to What if our graphics editor (e.g. Sketch) turned our designs into responsive web apps automatically?, in reply to Charles Maia , Jul 30, 2018

    WTF do you think happens in that week or two? Engineers aren't machines that convert your mockups to code. They solve complex problems that only a human being can do through problem-solving, abstraction and collaboration with the other layers of the stack.

    This comes across as incredibly naive tbh, no wonder you are struggling—I don't think you understand how any of it works.

    0 points
  • Posted to Designing for accessibility is not that hard, Jul 02, 2018

    This is a well written article and a good resource for those just starting out with a11y. Bit disappointed that it didn't deal with actually designing for a11y, which is hugely important. This involves not just technical stuff here but the IA, content, page structure, overall document semantics, hidden text to fill in gaps where visual cues are used, etc.

    This is something that needs to be done as early in the design process as possible and tested with users and iterated upon before production even starts. Without it, a11y just becomes a box-ticking exercise—you'll never know if your product is truly accessible.

    0 points
Load more comments