I'm pretty sure that was an intentional design choice to make the text look more like Markdown. Ordered lists increment by default — they went out of their way to disable that.
"High Fidelity Visualization" is an interesting term they've tried to coin, but I've had enough experience to know that just because you come into a meeting with a mock or prototype, doesn't necessarily make it a "nuclear" weapon that lets you build automatic consensus. When I'm presenting to a room filled with talented people, I would hope they would be smart enough to see through such a gimmick.
What's fascinating to me is that because it prevented the surrounding communities from growing at the expense of Kalamazoo, those districts invested even more in their schools and education infrastructure to compete with the city with The Promise. I would have predicted the exact opposite. Super interesting.
I agree with the commenter's initial point that learning any amount of programming will help a non-technical person to understand and better contribute to a technical startup or organization significantly. What I'm worried about is that non-technical people will skim this article and think that design is easier than coding. There's a rabbit hole in every discipline and my experience has been that the attributes that makes someone a decent programmer are usually the same attributes that makes someone a decent designer. In fact, I'd go as far to say that the attributes that make anyone decent at anything are usually the same for anything else.
So if you "want to learn to code" and for some reason cannot, then I'm going to bet you have other issues that prevents you from doing so, which is the sentiment Dan Shipper (the original comment this poster was responding to) basically attributed to "false constraints."
I guess the argument comes down to believing that coding (like most people believe about design) requires some innate talent to be able to do it. And while I believe that might be the case to be great at it, I truly do believe almost everyone should be able to learn to code (or design) if they truly want it enough.
Like with anything, I prefer people not to go into a field if they're not passionate about it. Don't code if you're not into it. And don't come into design because it's Plan B. Code because you love it. Design because you can't get enough of it. If you're non-technical and your passionate about wanting to build technical things, then you really only have one avenue for that outlet if you can't somehow convince others to help build those things for you and that's learn it the hard way.
You are reading into what I said. Nowhere in it do I say design is easy. It's on a site where I say programming is hard, so why would I claim design is easy? Hell, I can barely barely do a passable design so why on earth would I claim it's easy. Design is hard as hell.
I'm saying, if you want to do web startups, and you can't get into coding, then TRY PUTTING YOUR EFFORTS INTO LEARNING TO DO DESIGN. See? No implication at all that it's easier or harder, just different.
Thank you for saying this far more eloquently and admittedly less emotionally than I had originally written in the reply I decided not to post. I love LCTHW, but as a designer, this post was a little offensive to me - it read as "Well, if you can't do the hard stuff, do the easy stuff."
Basically, my gist was that web design is already overwhelmed with people that used it as a backup plan - be it print designers, graphic designers or general artists that realized the former two were all moving into web and that's where the money was. The outcome of this can be seen across the web; information hierarchy and complementary interaction design take a backseat to overdone graphics and bad UX.
If you're going to be designing for code, you're going to need to understand code, particularly CSS/JavaScript capabilities and fallbacks. It will make you a better designer and possibly help you transition into the dev you wanted to be.
> If you can lay out all the major screens and the design then that’s worth its weight in gold. Design is also just about as hard to find as programming.
Not every person is created equal. If you aren't sprinting successfully, maybe you'd be a better endurance athlete -- this isn't to say that sprinting is better than endurance, it is just saying that is is a different and complimentary skill that you might have success with. Queue Sly and the Family Stone
Oh I would absolutely encourage anyone who wants to be involved in web to try their hand at either, but if worse comes to worse and they don't find themselves particularly cut out for them, design tends to be the one that they stick with because it's easy to look like you produced "something" and there's always somebody out there willing to buy "something" if the price is right.
Having watched a few people struggle to the point where they are switched off of projects regularly and haven't left a job on their own terms, I think it is worth acknowledging that the allure of working in this/any industry may outshine one's passion to do so and it may be healthier to find greener pastures than to settle on the one that's "good enough". There are also a lot of auxiliary roles to designers and developers that they may find a lot more fulfilling and that give them the opportunity to learn over time.
After watching people try to learn to code for almost 30 years now I'm convinced that some people have the mental knack for it and others just don't and that some people will never be good coders no matter how hard they try.
They may, however, excel in a different discipline with different demands so why not explore those other avenues?
Zed is a master of subtle provocation (and not-so-subtle, if you are familiar with his other projects). I suspect that he doesn't actually think that it's easier to become a real designer than it is to be a programmer. But there's a certain amount of truth to the idea that one could pick up Photoshop, or a wireframing tool, or a bit of HTML and CSS, and start turning their ideas into designs much faster than one could learn enough programming to build a full application prototype. Working that insinuation into the title attracts readers.
I've been doing design-by-necessity on projects for 15 years. I even take time to study and understand design concepts. While I'm an OK UX guy, I still pretty much suck as a designer.
It's easily as hard as programming, but for very different reasons. And because of those reasons, it may be a good alternative for the "suit" partner to learn.
I think you nailed my issue. Based on the thoughtfulness of his response to Shipper, I'm pretty sure that his recommendation is not a statement about the lack of depth in the design field. The problem I have is packaging.
I'm not sold on doing this at the commit level, but we have been using Pull Requests on Github in this fashion for Wufoo and SurveyMonkey. We start with an initial commit to start the branch for a new feature and then immediately initiate a Pull Request. That pull request contains a list of items that need to be done for the feature and as it gets developed you can see how commits are working towards making that pull request ready. This also helps tremendously with code reviews because you can do them as the feature is being developed.
What's nice about this method for us is that you can just look at the list of active pull requests for a project and see what features are in active development and get an easy way to drill down into the progress of each.
I guess you could call it Pull Request Driven Development.
Because issues and PRs are hopelessly intermingled in Github, we create issues with the sole intent of creating an initial PR "feature/1234-api-auth" so we can reference and close the initial ticket.
The issue describes what is the problem and what needs to be accomplished, while the PR body describes what actions will be taken and the overall progress.
https://github.com/mrcoles/markdown-css/pull/4