3 ms·

I stick with a few basic guidelines: * Sketch out the idea on literal paper before committing it to working code. Paper is so much easier to get 'working'. *

I stick with a few basic guidelines: * Sketch out the idea on literal paper before committing it to working code. Paper is so much easier to get 'working'. * Borrow visually from other sites that I like and have similar intent. I don't have the time on side projects to go crazy breaking new UX ground. (And users probably don't want that anyway.) * Keep the idea simple and uncluttered. Maybe a specialist could get away with fancy stuff, but I'm not a specialist. * Try to offload functionality into the back end. If I can simplify the user experience by making the back end more intelligent, I do it. * Be very cautious about introducing technical complexity. Usually for side projects, I have a specific goal I want to achieve and limited time in which to achieve it. I'd rather not spend that time messing around with some fancy framework, unless I'm convinced I need it to satisfy my goal. * Reuse from my other work.There are a lot of aspects of, say, a website, that don't have to be uniquely redone for each. So it might quickly become cost effective to factor out something like a login flow UX. (And has the benefit of offering some degree of consistency across projects...)

ehnto 8y ago
I skip the draft step, but otherwise I am very similar. Simple, extremely lean and functional tooling and extremely simplified frontend functionality. If I can achieve good UX with CSS media queries and a light dusting of vanilla JS then that is all I will use. I also leverage new browser features where possible. The datepicker in some browsers suck, but it is native and I don't have to maintain it.
hnrodey 8y ago
Several of these resonate with me and align with my past experiences. * Create a paper/whiteboard design first. * Borrower from other sites/past projects. * KISS / minimize technical complexity. Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. Honestly it's great to work with and making UI's that have some degree of a pleasant user experience. Here are two projects I've worked on recently where I've used Vue.js. The first is via Vue-Cli and a true SPA app that is hosted through Amazon S3 and CloudFront. The second an ASP.NET Core app hosted on Heroku as a container. In both cases, Bootstrap has integrated very well with the Vue.js app. A driving factor for creating these has been to share my Vue.js knowledge with others. * https://github.com/ryanrodemoyer/ParlayTools https://github.com/ryanrodemoyer/ParlayTools - available @ https://d3itp7yns2kqcy.cloudfront.net https://d3itp7yns2kqcy.cloudfront.net * https://github.com/ryanrodemoyer/AccrualCalculator https://github.com/ryanrodemoyer/AccrualCalculator available @ https://accrual-calculator-prod.herokuapp.com https://accrual-calculator-prod.herokuapp.com Good luck!
- mschaef 8y ago
  > Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. After thirty years coding, I probably shouldn't admit this, but it's still a significant challenge to make these sorts of priority calls. This is even more true for side projects, where they're resource constrained by definition. It's easier to take risks and pay upfront costs when you have 40 hours a week to invest in a codebase than when it's only one or two hours a week. Mainly because I find it efficient for me to use, I tend to do most of my side project work these days in Clojure. I think a bit part of why it makes sense for me to do that is that I'm carrying in a bunch of previous experience in Lisp style languages, and Clojure aligns fairly well with the way I think about building systems. It also aligns well because most of my professional experience is in the JVM, so there's a fair amount of carry over. The reason I mention this is that I think it illustrates how subjective the notion of complexity can be. For me, in my context, it's simpler, but it's not hard to imagine it being absolutely the wrong choice for someone else. There's also the problem of when it makes sense to pay certain costs. I have a little todo list application I've used to run my life for the last few years. My initial design idea was to keep it simple with exclusively server side rendering of the HTML. This focus on a simple approach has generally been a positive thing, but there are increasingly often features I'd like to add where the existing architecture doesn't work. The path forward is easy to describe - port to an SPA - but the effort involved is more than I have time for. My short term unwillingness to pay the cost of building an SPA four years ago is coming back to haunt me, just a little bit. My solace there is that I probably wouldn't have actually had time to build the thing in the first place had I taken the time to make it an SPA. (And at least now I know that if I ever do make the port, it's likely to be something I actually use.) So not an easy set of decisions to make, by any means. > A driving factor for creating these has been to share my Vue.js knowledge with others. This is another aspect of side projects worth considering. Sometimes they're built to solve a 'business problem' and sometimes they're built for pedagogical reasons (either self or others). That can have a dramatic impact on architectural choices, etc.
paulftw 8y ago
Awesome list. One point I’d add that changed how I think about UI and UX is being aware when UI reflects internal code structure instead of just doing what a user would want to see. The latter is harder, so engineers tend to avoid it, often subconsciously.
- mschaef 8y ago
  > UI reflects internal code structure instead of just doing what a user would want to see. Some of that depends on the audience for the app. For a technically sophisticated user base, having an interface that comes closer to the level of the underlying implementation can be quite powerful (and give a system a feeling of gestalt or wholeness that's quite satisfying). That's one of the aspects of Emacs that I find the most valuable. A command is just a function in the underlying Lisp, etc. But for less technical users, or even technical users in a 'off hours' or less technicial setting, this sort of UI can require an unduly high investment.

ehnto 8y ago

I skip the draft step, but otherwise I am very similar. Simple, extremely lean and functional tooling and extremely simplified frontend functionality. If I can achieve good UX with CSS media queries and a light dusting of vanilla JS then that is all I will use. I also leverage new browser features where possible. The datepicker in some browsers suck, but it is native and I don't have to maintain it.

hnrodey 8y ago

Several of these resonate with me and align with my past experiences. * Create a paper/whiteboard design first. * Borrower from other sites/past projects. * KISS / minimize technical complexity. Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. Honestly it's great to work with and making UI's that have some degree of a pleasant user experience. Here are two projects I've worked on recently where I've used Vue.js. The first is via Vue-Cli and a true SPA app that is hosted through Amazon S3 and CloudFront. The second an ASP.NET Core app hosted on Heroku as a container. In both cases, Bootstrap has integrated very well with the Vue.js app. A driving factor for creating these has been to share my Vue.js knowledge with others. * https://github.com/ryanrodemoyer/ParlayTools https://github.com/ryanrodemoyer/ParlayTools - available @ https://d3itp7yns2kqcy.cloudfront.net https://d3itp7yns2kqcy.cloudfront.net * https://github.com/ryanrodemoyer/AccrualCalculator https://github.com/ryanrodemoyer/AccrualCalculator available @ https://accrual-calculator-prod.herokuapp.com https://accrual-calculator-prod.herokuapp.com Good luck!

mschaef 8y ago
> Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. After thirty years coding, I probably shouldn't admit this, but it's still a significant challenge to make these sorts of priority calls. This is even more true for side projects, where they're resource constrained by definition. It's easier to take risks and pay upfront costs when you have 40 hours a week to invest in a codebase than when it's only one or two hours a week. Mainly because I find it efficient for me to use, I tend to do most of my side project work these days in Clojure. I think a bit part of why it makes sense for me to do that is that I'm carrying in a bunch of previous experience in Lisp style languages, and Clojure aligns fairly well with the way I think about building systems. It also aligns well because most of my professional experience is in the JVM, so there's a fair amount of carry over. The reason I mention this is that I think it illustrates how subjective the notion of complexity can be. For me, in my context, it's simpler, but it's not hard to imagine it being absolutely the wrong choice for someone else. There's also the problem of when it makes sense to pay certain costs. I have a little todo list application I've used to run my life for the last few years. My initial design idea was to keep it simple with exclusively server side rendering of the HTML. This focus on a simple approach has generally been a positive thing, but there are increasingly often features I'd like to add where the existing architecture doesn't work. The path forward is easy to describe - port to an SPA - but the effort involved is more than I have time for. My short term unwillingness to pay the cost of building an SPA four years ago is coming back to haunt me, just a little bit. My solace there is that I probably wouldn't have actually had time to build the thing in the first place had I taken the time to make it an SPA. (And at least now I know that if I ever do make the port, it's likely to be something I actually use.) So not an easy set of decisions to make, by any means. > A driving factor for creating these has been to share my Vue.js knowledge with others. This is another aspect of side projects worth considering. Sometimes they're built to solve a 'business problem' and sometimes they're built for pedagogical reasons (either self or others). That can have a dramatic impact on architectural choices, etc.

paulftw 8y ago

Awesome list. One point I’d add that changed how I think about UI and UX is being aware when UI reflects internal code structure instead of just doing what a user would want to see. The latter is harder, so engineers tend to avoid it, often subconsciously.

mschaef 8y ago
> UI reflects internal code structure instead of just doing what a user would want to see. Some of that depends on the audience for the app. For a technically sophisticated user base, having an interface that comes closer to the level of the underlying implementation can be quite powerful (and give a system a feeling of gestalt or wholeness that's quite satisfying). That's one of the aspects of Emacs that I find the most valuable. A command is just a function in the underlying Lisp, etc. But for less technical users, or even technical users in a 'off hours' or less technicial setting, this sort of UI can require an unduly high investment.