Ask HN: How do you begin the process of developing a web application?
73 comments
Write something, anything! It doesn't even matter how good it is, just get something up and running. Then change it. Change it again. Repeat.
Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish.
I've tried many different approaches, but this one has worked best for me. It may seem counter intuitive, but I have found that things move along much faster when I enhance a minimal product than if I stew with my thoughts for too long.
[EDIT: No offense taken, but I took out the template. Now close your browser and go write your own.]
Have you ever written anything before? Good. Then take the closest thing you have from your repository, strip out the code that doesn't apply and file it under the new name. There. You're already x% done. Now finish.
I've tried many different approaches, but this one has worked best for me. It may seem counter intuitive, but I have found that things move along much faster when I enhance a minimal product than if I stew with my thoughts for too long.
[EDIT: No offense taken, but I took out the template. Now close your browser and go write your own.]
No offense, but please don't use this template :)
I didn't understand what happened with the template and what it was.
Don't look a gift horse in the mouth.
I'm with Ed on this one, with one small variation, every fifth project or so I start from a blank piece of paper just to get rid of the cruft that will build up otherwise.
That way I still have the 'blank paper elephant' to stare at every now and then but at least not every project and I find that re-writing stuff it usually comes out much better on the next iteration.
It's like remodeling houses, every now and then it pays off to raze the thing to the ground and start over instead of adapting the house to a new occupant.
That way I still have the 'blank paper elephant' to stare at every now and then but at least not every project and I find that re-writing stuff it usually comes out much better on the next iteration.
It's like remodeling houses, every now and then it pays off to raze the thing to the ground and start over instead of adapting the house to a new occupant.
This is exactly the way I work - I almost never actually start from scratch.
100% right. Get something working on the screen as soon as possible. Then show it to your designer and product people, and get immediate feedback about whether it looks like it's going to work for the audience or not.
You probably are never going to use the original code you put down, so its kind of irrelevant how you start designing your web app. The most important thing is to start working. By doing this you will know what works and what doesn't. This will help you in your next iteration.
After following the anti-planning approach for a long time, with dozens of half-finished pet projects to show for it, it seems approximately as good as procrastination (for me). If I get excited about something and start tapping away at the keyboard, I'm often left with a couple thousand lines of code and the realization that there are some major components that could have been thought out much better. The joy I originally had in creating it takes a major blow when faced with major rewrites (and the thought of all of the wasted time that could have been better spent thinking about it).
Nowadays, I'll let a project incubate in my head for a few days/weeks/months and approach the keyboard with a solid plan in mind and a well reasoned, well designed feature-set/interface.
But if you really don't have time for an incubation period, write your schema out first. This exposes so many design flaws in the beginning while it's still very easy to manipulate. This should be the "contract" you sign with your blood for the vast majority of apps you'll write for the web, and you should be spending a good deal of time thinking about it (for any non-trivial app) then, not later when you're atop a few thousands lines of uselessness.
Nowadays, I'll let a project incubate in my head for a few days/weeks/months and approach the keyboard with a solid plan in mind and a well reasoned, well designed feature-set/interface.
But if you really don't have time for an incubation period, write your schema out first. This exposes so many design flaws in the beginning while it's still very easy to manipulate. This should be the "contract" you sign with your blood for the vast majority of apps you'll write for the web, and you should be spending a good deal of time thinking about it (for any non-trivial app) then, not later when you're atop a few thousands lines of uselessness.
I buy a $1 project notebook, put the name of the project on the front page, and start jotting down things in the notebook. This could be database tables, paper mockups, notes on features to add, roadmap, whatever.
Eventually, on a day I'm feeling particularly inspired, I can't stop myself from coding. This sees me make a quickie Rails development environment and push hard to get One Cool Thing accomplished. As long as I have one thing done, further attempts at coding don't feel like breaking ground (hard work!), they're just extensions to existing functional code.
You'll laugh, but the One Cool Thing I did with Appointment Reminder was making it so the logged in user can switch the color scheme for her pages. This has rather little practical utility but it was quick to do and satisfied my monkey brain: "visual changes == making progress, ergo, five visual changes == LOTS of progress."
Often the first thing I do is something with domain logic that I can only execute through the console to start out with. Crikey I love my Rails console. Right now for client work I have a program which goes to a particular government agency, slurps down a gigabyte of data, does some number crunching, and then tells you things any well-informed high schooler knows about a particular subject. The difference between the program and the well-informed high schooler is that the high schooler would get bored after listing 5 or 10 of the facts but the program can punch through thousands.
Eventually, on a day I'm feeling particularly inspired, I can't stop myself from coding. This sees me make a quickie Rails development environment and push hard to get One Cool Thing accomplished. As long as I have one thing done, further attempts at coding don't feel like breaking ground (hard work!), they're just extensions to existing functional code.
You'll laugh, but the One Cool Thing I did with Appointment Reminder was making it so the logged in user can switch the color scheme for her pages. This has rather little practical utility but it was quick to do and satisfied my monkey brain: "visual changes == making progress, ergo, five visual changes == LOTS of progress."
Often the first thing I do is something with domain logic that I can only execute through the console to start out with. Crikey I love my Rails console. Right now for client work I have a program which goes to a particular government agency, slurps down a gigabyte of data, does some number crunching, and then tells you things any well-informed high schooler knows about a particular subject. The difference between the program and the well-informed high schooler is that the high schooler would get bored after listing 5 or 10 of the facts but the program can punch through thousands.
Personally, I dive right into the DB Schema. I use a modeling tool and just start with the basic relationships. For example, a User table and then as I think of features I think about how I will need to store them, how each entity relates to the other, etc. I'm a nut for normalization. At some point the schema is good enough to start coding some basic pages to login and do things. Of course, the schema never stays the same but evolves with the app.
I think the biggest reason I enjoy doing this is because I'm driven by visible progress. I do just enough DB work to then do a little bit of coding so I can do something in the app. Basically giving my self little feature goals here and there.
I think the biggest reason I enjoy doing this is because I'm driven by visible progress. I do just enough DB work to then do a little bit of coding so I can do something in the app. Basically giving my self little feature goals here and there.
I usually begin with the database as well. I start creating tables for the basics of whatever I'm building and it's here that I think of new tables to complement the main ones. After that, it's mostly CRUD with some logic.
Same here. I use django though so it's basically just typing up some quick models. If not, I'll write them in notepad in the form of:
@Table:
- fieldname char
- field2 intI like to start with the underlying structure of the data as well, which for database-driven web sites means the schema.
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks.
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks.
Sinatra, Haml, Blueprint, Sass, jQ.
I have a template that does login, tabs, and layout.
I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup.
I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form.
Prune down, customize, work out page flows (which is easy once I have a base of things that works properly), pick a couple hotspots that want Ajax-y behavior (not because it's hard, but because whenever I start a project Ajax-y, I'm always unhappy with how brittle the result is).
I use Compass for the Blueprint/Sass style, but I don't waste too much time making things look good; my template gets me to about 80% of "competant" and 85-90% of "usable" and then, if I care, I spend money on a designer. I find knowing that I'm going to do this is liberating; means I don't waste a whole lot of time lining up pixels.
I never touch Photoshop. I can't mock up graphically. My brain just doesn't work that way. But then, I came to web dev from 10+ years of Unix commandline dev.
I have a template that does login, tabs, and layout.
I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup.
I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form.
Prune down, customize, work out page flows (which is easy once I have a base of things that works properly), pick a couple hotspots that want Ajax-y behavior (not because it's hard, but because whenever I start a project Ajax-y, I'm always unhappy with how brittle the result is).
I use Compass for the Blueprint/Sass style, but I don't waste too much time making things look good; my template gets me to about 80% of "competant" and 85-90% of "usable" and then, if I care, I spend money on a designer. I find knowing that I'm going to do this is liberating; means I don't waste a whole lot of time lining up pixels.
I never touch Photoshop. I can't mock up graphically. My brain just doesn't work that way. But then, I came to web dev from 10+ years of Unix commandline dev.
I also recommend DataMapper. You don't mention a framework, but Sinatra is very simple and a good choice for banging out a web app fast.
Start with the main page -- whatever you (or your users, if you plan to have them) will be looking at most often. Put text on the page, even if it's static Lorem Ipsum. Or, as Tom said, the handlers for GET /foo and POST /foo. IMO, it is much easier to live with ugly pages at first than to start out with a rigid idea of a design and then struggle to cram stuff into that. Getting the CSS just so seems to take so much more time than anything else -- I prefer to save that for last.
After your main page, start asking yourself questions about how your app is going to be used. Does it need admin pages? Will it need a login page? What kind of data does each page have and how will it be displayed (eg, a directory tree with collapsible subitems)? Write all of this down. Really.
By the time you're done with this, you'll have some idea of how many pages/views you'll want, and some mental idea they should look like. Do a web search for designer portfolios -- this is a good way to find ideas for UI elements in similar apps. Use Sass + Blueprint to put the text in columns and boxes. If you use Firefox, I highly recommend Firebug (Safari has Web Inspector, but it never works quite the way I expect it to). Print out these pages and mark it up using your favorite color of crayon. Designate where stuff like images, forms and tabs will go. Take a look at CSSEdit, too.
Start with the main page -- whatever you (or your users, if you plan to have them) will be looking at most often. Put text on the page, even if it's static Lorem Ipsum. Or, as Tom said, the handlers for GET /foo and POST /foo. IMO, it is much easier to live with ugly pages at first than to start out with a rigid idea of a design and then struggle to cram stuff into that. Getting the CSS just so seems to take so much more time than anything else -- I prefer to save that for last.
After your main page, start asking yourself questions about how your app is going to be used. Does it need admin pages? Will it need a login page? What kind of data does each page have and how will it be displayed (eg, a directory tree with collapsible subitems)? Write all of this down. Really.
By the time you're done with this, you'll have some idea of how many pages/views you'll want, and some mental idea they should look like. Do a web search for designer portfolios -- this is a good way to find ideas for UI elements in similar apps. Use Sass + Blueprint to put the text in columns and boxes. If you use Firefox, I highly recommend Firebug (Safari has Web Inspector, but it never works quite the way I expect it to). Print out these pages and mark it up using your favorite color of crayon. Designate where stuff like images, forms and tabs will go. Take a look at CSSEdit, too.
> But then, I came to web dev from 10+ years of Unix commandline dev.
Same here, and I'm beginning to think that that is slowly becoming a handicap rather than an advantage.
Same here, and I'm beginning to think that that is slowly becoming a handicap rather than an advantage.
Meh. I feel like I get shit done. I've seen a lot of very "professional" web code (note "day job"), and I think my stuff stands up OK.
If I was 22 years old and trying to impress YC with a demo, or launching in front of the mass market with only my own design skills and no cash for designers, I'd be worried that my front-end skills were hurting me. But after a couple years of contact with customers and prospects: front-end is definitely not what's hurting us.
There are 3 other devs on my team, and while I've been convicted for a while of the idea that we need to hire someone crazy excellent with jQ, we're all former backend people. I think we get things done just fine.
I don't have a "methodology" so much as I have a semiconscious bias towards a process that keeps me typing and doesn't give me a lot of opportunities to stop and noodle --- at least not until I have so much traction that dropping things would be painful.
I know (especially from reading the threads here) that most front-end people have a definite preferencing for designing and wireframing up front. They're probably right. But I don't find refactoring and redesigning to be so painful that it outweighs the inertia I'm fighting when I first start a project. I need to fight past the inertia before I can profitably spend energy on design.
If I was 22 years old and trying to impress YC with a demo, or launching in front of the mass market with only my own design skills and no cash for designers, I'd be worried that my front-end skills were hurting me. But after a couple years of contact with customers and prospects: front-end is definitely not what's hurting us.
There are 3 other devs on my team, and while I've been convicted for a while of the idea that we need to hire someone crazy excellent with jQ, we're all former backend people. I think we get things done just fine.
I don't have a "methodology" so much as I have a semiconscious bias towards a process that keeps me typing and doesn't give me a lot of opportunities to stop and noodle --- at least not until I have so much traction that dropping things would be painful.
I know (especially from reading the threads here) that most front-end people have a definite preferencing for designing and wireframing up front. They're probably right. But I don't find refactoring and redesigning to be so painful that it outweighs the inertia I'm fighting when I first start a project. I need to fight past the inertia before I can profitably spend energy on design.
In what ways do you find AJAX brittle?
Also, could you explain (I think it's css/ruby/REST/psuedo code for an unordered list comprised of the foos - but how is that for a feature?):
Also, could you explain (I think it's css/ruby/REST/psuedo code for an unordered list comprised of the foos - but how is that for a feature?):
%ul#foos // - @foos.each do |foo|Sorry. I meant // as a line break. %whatever is a Haml tag that generates <whatever>. - @foos.each do |foo| is "foreach foo in @foos".
I don't find Ajax brittle, I find my own designs when I set out from the beginning to make everything Ajaxy brittle. Brittle here meaning:
* Navigation is always funky
* I wind up with tangled messes of jQ callbacks
* I wind up with Sinatra methods that are laser-targeted for specific jQ interactions instead of general things I can use in multiple ways
Generally, the app just doesn't work as well. I think that's because it's slightly but deceptively harder to get a site driven mostly with JS working as well as a plain-ol-webapp.
I don't find Ajax brittle, I find my own designs when I set out from the beginning to make everything Ajaxy brittle. Brittle here meaning:
* Navigation is always funky
* I wind up with tangled messes of jQ callbacks
* I wind up with Sinatra methods that are laser-targeted for specific jQ interactions instead of general things I can use in multiple ways
Generally, the app just doesn't work as well. I think that's because it's slightly but deceptively harder to get a site driven mostly with JS working as well as a plain-ol-webapp.
thanks!
1. Draw some ideas out on paper, and work out the minimal viable feature set.
For some people this is just a buzz word, but I'm a firm believer in it.
2. Use Balsamiq mockups to neatly replicate what I've drawn and make adjustments
(this step could be skippable, but it only takes 10 minutes generally, so
it's nice to have)
3. If it's client work, export the mockups as PNGs and send them a link
4. Create the design in Photoshop, rarely pixel perfect, I just use it as a
supped-up Balsamiq, to get a feel for the design
5. Create a Rails or Sinatra base, depending on the complexity of the project.
For a Rails project, I git clone http://github.com/ashleyw/Slate
6. Write some Cucumber features, referring to any notes or drawings I made in
step #1
7. Design the model structure, write some unit tests for them, and then
implement each model until the tests pass
8. Once I have a model basis, I move on to the controllers and views (HAML),
going by the Cucumber features I wrote until they pass. Semantic markup is
important here, but styling is not.
9. Replicate the Photoshop design in CSS (or SASS)
10. Launch
11. Reiterate adding features which didn't fit into first versionAs a programmer I'm finding out it's best not to code anything immediately. Think [first] about the idea, conceptualize it, let it soak in your brain. Take some time to let it refine itself a bit.
[Next] would be a marketing website. Grab a theme off themeforest.net and work on a one page slideshow explaining your idea. Do this from a marketing perspective: sell it to your customers.
I find this is crucial because it forces you to refine your idea into a marketable idea. If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable. What this also does is sell yourself on the idea. Once you've taken the time to craft out some great marketing copy, you begin to think "hey this does sound like a good idea!". You also have an easy way to get initial feedback from your network.
[Finally] after using your marketing site to get inner-circle feedback, you go after some customer development. Customers tend to need to see an actual working something though so it's probably best to code out and MVP. I'd start with modeling the data and then work out the core features and at long last, I get the joy of coding!
[Next] would be a marketing website. Grab a theme off themeforest.net and work on a one page slideshow explaining your idea. Do this from a marketing perspective: sell it to your customers.
I find this is crucial because it forces you to refine your idea into a marketable idea. If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable. What this also does is sell yourself on the idea. Once you've taken the time to craft out some great marketing copy, you begin to think "hey this does sound like a good idea!". You also have an easy way to get initial feedback from your network.
[Finally] after using your marketing site to get inner-circle feedback, you go after some customer development. Customers tend to need to see an actual working something though so it's probably best to code out and MVP. I'd start with modeling the data and then work out the core features and at long last, I get the joy of coding!
This HN post was a pretty good example of what you describe (not complete to your specs, but a nice start): http://news.ycombinator.com/item?id=1365807
The professional logo goes a long way toward making it feel legit.
> If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable.
This may also be a function of your marketing/copy-writing ability; it doesn't necessarily correlate with idea quality or marketability. It could also indicate that your focus simply needs refinement.
The professional logo goes a long way toward making it feel legit.
> If you are taking 3 paragraphs to explain what your app does, what problem it solves, or why people should care, well your idea is probably not that great, much less marketable.
This may also be a function of your marketing/copy-writing ability; it doesn't necessarily correlate with idea quality or marketability. It could also indicate that your focus simply needs refinement.
Hi Joel, thanks for replying. The part about the marketing copy is surely correct. But for many HN'ers including myself, I would need to be good at marketing copy if I want my business to become in any way sustainable. Many people on here are flying solo, for better or worse. But it would be clear to say your business (i.e. someone inside your business) needs to be good at marketing!
I don't do anything once I have the initial idea.
I let it sit around in my head for a few days/ weeks... If it keeps bothering me then I try and get the core of the functionality down as quickly as possible -
I get something online which I show my friends and family. Once I've taken, or not taken, their advice I move forward.
I push forward a bit with my gut feeling and get my girlfriend to work on the design. (She's an awesome designer, I'm really lucky!)
I flesh it out around the edges, user registration, 404, 500 error pages whilst I'm waiting for the designs. (Or I just work on something else.)
And then I'm in "beta."
I let it sit around in my head for a few days/ weeks... If it keeps bothering me then I try and get the core of the functionality down as quickly as possible -
I get something online which I show my friends and family. Once I've taken, or not taken, their advice I move forward.
I push forward a bit with my gut feeling and get my girlfriend to work on the design. (She's an awesome designer, I'm really lucky!)
I flesh it out around the edges, user registration, 404, 500 error pages whilst I'm waiting for the designs. (Or I just work on something else.)
And then I'm in "beta."
You can try what the 37signals guys recommend at http://gettingreal.37signals.com/ch06_From_Idea_to_Implement...
1. Brainstorm
2. Paper sketches
3. HTML + CSS mockup
4. CodeI tend to think in terms of architecture, so how the data will fit together and what the major compontents will be. The functional requirements are usually something that crystalize in my head on the back-burner over a period of weeks until I pull the trigger and jump in. I often write some throw-away code that captures some of the non-trivial couplings between pieces as a proof of concept and then start filling in the gaps upwards.
Usually on the interface side there's a separate process that meets in the middle. I'll often either do some dummy HTML pages or (yeah, laugh) Keynote slides that give me an idea for the interactional mechanics.
That said, and it probably shows, my strong suit is in developing libraries, not applications, and I tend to paint with that brush even when doing apps.
Usually on the interface side there's a separate process that meets in the middle. I'll often either do some dummy HTML pages or (yeah, laugh) Keynote slides that give me an idea for the interactional mechanics.
That said, and it probably shows, my strong suit is in developing libraries, not applications, and I tend to paint with that brush even when doing apps.
That's pretty much where my webdev style comes from too --- library design --- so that, how I write C library code (foo_new(), foo_release(), foo_get(), foo_put(), etc) just gets expressed as (say) Sinatra handlers.
Then I call the library in different ways to build something useful out of it.
Never thought of it that way, but that makes sense to me.
Then I call the library in different ways to build something useful out of it.
Never thought of it that way, but that makes sense to me.
1. Write 2-3 sentences about each potential user type for your app.
2. Assume each of the users will spend a max 1-3 minutes on your app, do just 1-3 actions. Which would these minutes be spent on, what are those key actions?
3. Find some white paper and a thick calligraphy pen. Draw the flow in very broad outlines, as a storyboard. Max 3-4 screens per flow. Paper and pen are the best. Forget computers. Forget details.
4. Think if those key flows are something users are willing to pay money for. If not, start over from 1.
5. Once you have a few short flows where users would go mad and pour money over you, start thinking about wireframes and details of the mockups.
There are several attack angles I tackle in semi-random order:
1. What problem am I really trying to solve? The point is to think about the users. I draw boxes that walk through the user sessions I want to support. For example, "user wants to do X lands on the site, they find the link that says Do X, they click on it, which shows them a screen with UI elements 1, 2, and 3....". They're called storyboards, and you don't need to be very detailed.
2. Knowing what I want to serve to the user, I think about the data that needs to be stored, how I'm going to obtain it, how to store it (database choice + schema), and other backend plumbing bits. This step is critical as I'm a firm believer that your database schema is a competitive advantage of a business. Get it right and you'll be able to serve your users better. However, it's important to realize that you won't get it right first time, and even if you do, it will need to evolve with your app. This is why I love schema-less databases.
3. With all this sorted, I tie up with a web framework I've written. It handles the routing, has data validation/sanitization helpers, handles user authentication, and all the other functions a web app needs. I just copy/paste these standard files into the new project's folder and I'm well on my way into the project because I can start focusing on the business logic.
Yes I plan on open sourcing this framework when I get a chance. It's constantly evolving though and there a few things I need to fix before releasing.
1. What problem am I really trying to solve? The point is to think about the users. I draw boxes that walk through the user sessions I want to support. For example, "user wants to do X lands on the site, they find the link that says Do X, they click on it, which shows them a screen with UI elements 1, 2, and 3....". They're called storyboards, and you don't need to be very detailed.
2. Knowing what I want to serve to the user, I think about the data that needs to be stored, how I'm going to obtain it, how to store it (database choice + schema), and other backend plumbing bits. This step is critical as I'm a firm believer that your database schema is a competitive advantage of a business. Get it right and you'll be able to serve your users better. However, it's important to realize that you won't get it right first time, and even if you do, it will need to evolve with your app. This is why I love schema-less databases.
3. With all this sorted, I tie up with a web framework I've written. It handles the routing, has data validation/sanitization helpers, handles user authentication, and all the other functions a web app needs. I just copy/paste these standard files into the new project's folder and I'm well on my way into the project because I can start focusing on the business logic.
Yes I plan on open sourcing this framework when I get a chance. It's constantly evolving though and there a few things I need to fix before releasing.
Personally this is what I do:
1) Idea
2) Write a small paragraph explaining the idea
3) Derive features
4) Make todo list
5) Make mockups using mockingbird (awesome tool)
6) Write some code
7) Get bored and go back to 1) (not recommended)
Between 5 and 6 It should be better to work on the design rather than code. Code should be last imo. Also I hope someone could erase step7 and actually launch the product :)
1) Idea
2) Write a small paragraph explaining the idea
3) Derive features
4) Make todo list
5) Make mockups using mockingbird (awesome tool)
6) Write some code
7) Get bored and go back to 1) (not recommended)
Between 5 and 6 It should be better to work on the design rather than code. Code should be last imo. Also I hope someone could erase step7 and actually launch the product :)
It may work well for you, and you should certainly feel free to work however you like, but I've found that diving into the code as early as possible works better for me.
I'm generally driven by seeing something working, even if it's only working enough that I can see some data on a page or have a single button that makes something happen.
If I can keep a good decoupling between my views and my models it's pretty easy to go back whenever I get the itch and make things look nicer without touching anything else. Unless you have a lot of javascript doing intense dom operations on a page you should be able to redesign it at will without worrying about breaking anything else, so I don't really worry about getting it right the first time, or really any time unless I'm getting ready to show it someone who's going to judge it on visual rather than functional grounds.
I've found (and, again, this may only apply to me and not you) that leaving design for later helps keep me from getting bogged down in details and losing my steam. If I have a very concrete picture of how something should look in my head I start worrying about getting my boxes to line up right and why my line heights are off and all that stuff that doesn't actually contribute to getting anything working. If I've purposely left the design aside I've in essence given myself permission to be okay with things looking crappy until I feel like fixing it, which helps keep me going on things that actually contribute to working code.
I'm generally driven by seeing something working, even if it's only working enough that I can see some data on a page or have a single button that makes something happen.
If I can keep a good decoupling between my views and my models it's pretty easy to go back whenever I get the itch and make things look nicer without touching anything else. Unless you have a lot of javascript doing intense dom operations on a page you should be able to redesign it at will without worrying about breaking anything else, so I don't really worry about getting it right the first time, or really any time unless I'm getting ready to show it someone who's going to judge it on visual rather than functional grounds.
I've found (and, again, this may only apply to me and not you) that leaving design for later helps keep me from getting bogged down in details and losing my steam. If I have a very concrete picture of how something should look in my head I start worrying about getting my boxes to line up right and why my line heights are off and all that stuff that doesn't actually contribute to getting anything working. If I've purposely left the design aside I've in essence given myself permission to be okay with things looking crappy until I feel like fixing it, which helps keep me going on things that actually contribute to working code.
[deleted]
It doesn't work for me, because I'm bad at design unfortunately. But from my experience from client projects where I dive into code first to implement specs from my clients without having them a final design usually tend to be slow progressing projects. Sometimes they die half way because it works but it looks terrible and the user experience sucks, even though they know its not finished yet, it kills motivation by a dissapointing user experience.
If you have a design which looks awesome, at least for me, I have greater motivation to get it work. The more detailed and comprehensive the design is, the more eager I am to make it work.
But again, this is what works for projects I've done for clients. Personally I don't have any good finished projects, none of the methods I tried worked there.
If you have a design which looks awesome, at least for me, I have greater motivation to get it work. The more detailed and comprehensive the design is, the more eager I am to make it work.
But again, this is what works for projects I've done for clients. Personally I don't have any good finished projects, none of the methods I tried worked there.
Many project float around my head for a bit of time. If something seems persistent I tend to make some notes on it to track ideas, features, core concepts, whatever.
If I decide to actually do it, I kick off a Ramaze project. This lets me start fast, light and simple while giving me a solid migration path should the app get complex. Last thing I want to do is have to change frameworks midway through; it'll be an excuse to not do stuff. I can start with a single-file app and build out as much as needed.
I use Rhesus to jumpstart such things, with personalized templates for assorted needs. I get the layout I want with the core files I know I use, skip the cruft.
Then I iterate. I put pretty much every app into a git repo so I can easily try stuff and not get lost down some dead end.
I also like using Selenium to drive test cases from a user perspective, see that I have important site-wide behavior in place and working. And it lets me automatically "walk" an app and mull over the big picture.
If I decide to actually do it, I kick off a Ramaze project. This lets me start fast, light and simple while giving me a solid migration path should the app get complex. Last thing I want to do is have to change frameworks midway through; it'll be an excuse to not do stuff. I can start with a single-file app and build out as much as needed.
I use Rhesus to jumpstart such things, with personalized templates for assorted needs. I get the layout I want with the core files I know I use, skip the cruft.
Then I iterate. I put pretty much every app into a git repo so I can easily try stuff and not get lost down some dead end.
I also like using Selenium to drive test cases from a user perspective, see that I have important site-wide behavior in place and working. And it lets me automatically "walk" an app and mull over the big picture.
1. Top-level requirements: What problem or problems is this application going to solve, and for whom? If you can't answer these questions clearly, you aren't building a serious application, you're just playing around. (This does not mean that you can't change your goals later, but you should always be building towards a clear, specific target.)
2. Functional requirements: What are the use cases, and how will the user interact with the application in each of them? Use storyboards, mock-ups, whatever helps you to understand what the application will do from the user's point of view.
3. High-level design: How will you model the data and functionality you've identified in the previous steps? Typically for a web app, a lot of this will be about setting up a data store server-side and figuring out how to implement any interactive behaviour client-side. You don't have to work out all the little details at this stage, but you need to choose a viable technology stack and know how the big picture is going to look.
4. Start prototyping: Set up the basics, enough to represent one key feature or perhaps a small group of related features, and create enough of the model/database behind the scenes to support it. Again, you don't have to code up every last bit of HTML and CSS at first, but you need to have a general idea of how things are going to fit together.
5. Refine what you've got and add further features and more details to the model, until you start to see how things are coming together. Go back often to check that the design and implementation are still meeting the requirements. Go back to the requirements themselves and make sure they are still appropriate as you gain experience in the field and/or you receive feedback from users/prospects.
It's very trendy to just dive in at about step 4 and starting hacking away, at least among the young, entrepreneurial types who seem to dominate forums like HN. By all means try it: if nothing else, you will learn why steps 1-3 are important.
Still, please don't bet your life savings on the project getting anywhere if you don't at least know where you think you're going before you start. You might well find that you change direction on the way, but aside from a few high profile exceptions, it is relatively rare in reality to see a successful business where someone just started coding something up one day and fluked their way into running a serious, profitable business before time and money ran out. Good ideas aren't worth much without a good implementation, but implementations aren't worth anything at all if they solve a problem no-one has.
2. Functional requirements: What are the use cases, and how will the user interact with the application in each of them? Use storyboards, mock-ups, whatever helps you to understand what the application will do from the user's point of view.
3. High-level design: How will you model the data and functionality you've identified in the previous steps? Typically for a web app, a lot of this will be about setting up a data store server-side and figuring out how to implement any interactive behaviour client-side. You don't have to work out all the little details at this stage, but you need to choose a viable technology stack and know how the big picture is going to look.
4. Start prototyping: Set up the basics, enough to represent one key feature or perhaps a small group of related features, and create enough of the model/database behind the scenes to support it. Again, you don't have to code up every last bit of HTML and CSS at first, but you need to have a general idea of how things are going to fit together.
5. Refine what you've got and add further features and more details to the model, until you start to see how things are coming together. Go back often to check that the design and implementation are still meeting the requirements. Go back to the requirements themselves and make sure they are still appropriate as you gain experience in the field and/or you receive feedback from users/prospects.
It's very trendy to just dive in at about step 4 and starting hacking away, at least among the young, entrepreneurial types who seem to dominate forums like HN. By all means try it: if nothing else, you will learn why steps 1-3 are important.
Still, please don't bet your life savings on the project getting anywhere if you don't at least know where you think you're going before you start. You might well find that you change direction on the way, but aside from a few high profile exceptions, it is relatively rare in reality to see a successful business where someone just started coding something up one day and fluked their way into running a serious, profitable business before time and money ran out. Good ideas aren't worth much without a good implementation, but implementations aren't worth anything at all if they solve a problem no-one has.
"you should always be building towards a clear, specific target"
Why?
Why?
Because if you don't know what you're building, you aren't really following a process at all, you're just experimenting randomly and hoping something good happens. Personally, I advocate relying on thinking things through and solving real problems rather than trusting to blind luck that you will somehow wind up solving a problem that someone has and will pay you to fix. YMMV.
"All this has happened before. All this will happen again" -- Pythia, BSG.
The first thing I do is research the daylights out of every competitive product I can find and compile a super set of features of all of them, noting pricing, positioning, messaging, etc.
Then I circle the features that matter to me and I add my own secret sauce features. Then I turn the computer off and start sketching.
Sketching isn't the act of coding or even designing. It's the act of thinking. Look at Leonardo's sketches -- particularly the ones of the human body. http://www.drawingsofleonardo.org He isn't documenting in so much as he's working out what he thinks about how something will work, not just on the outside but on the inside as well. This is particularly true for his anatomy sketches. IMHO he would have been an awesome software designer.
I believe that coding is the art of thinking clearly. Lack of clarity in what you're building almost always results in bad code, the kind that no amount of tweeking can fix.
IMHO the absolute best prototyping tool out there is graph paper and pencil. Personally I like the marbled notebooks because they can take a beating and you can write on them reclining.
Once you've got all the screens of your site drawn out and even some copy written in the margins then you can turn the computer back on and revisit each of those competitive sites and see if your idea still hunts. If it still does then start coding.
The first thing I do is research the daylights out of every competitive product I can find and compile a super set of features of all of them, noting pricing, positioning, messaging, etc.
Then I circle the features that matter to me and I add my own secret sauce features. Then I turn the computer off and start sketching.
Sketching isn't the act of coding or even designing. It's the act of thinking. Look at Leonardo's sketches -- particularly the ones of the human body. http://www.drawingsofleonardo.org He isn't documenting in so much as he's working out what he thinks about how something will work, not just on the outside but on the inside as well. This is particularly true for his anatomy sketches. IMHO he would have been an awesome software designer.
I believe that coding is the art of thinking clearly. Lack of clarity in what you're building almost always results in bad code, the kind that no amount of tweeking can fix.
IMHO the absolute best prototyping tool out there is graph paper and pencil. Personally I like the marbled notebooks because they can take a beating and you can write on them reclining.
Once you've got all the screens of your site drawn out and even some copy written in the margins then you can turn the computer back on and revisit each of those competitive sites and see if your idea still hunts. If it still does then start coding.
mkdir mynewapp
cd mynewapp
git init mynewapp
mkvirtualenv mynewapp
echo Django > requirements.txt
pip install -r requirements.txtDraw a mockup on paper and figure out how you want your app to work. Once it's done, get the simplest case working in real software.
I find that by getting something simple working helps me keep motivation whilst going forward, even if the code is crappy. Conversely, I've started a non-trivial number of webapps by designing a DB schema and an application architecture, each of which left me burnt out before anything of value was even written.
I find that by getting something simple working helps me keep motivation whilst going forward, even if the code is crappy. Conversely, I've started a non-trivial number of webapps by designing a DB schema and an application architecture, each of which left me burnt out before anything of value was even written.
Personally, I just write. I write pages and pages of stream-of-consciousness thinking about the application, everything from how it will look to how the backend will function to how it will make money. Once I'm done with that, I sleep on it (as it's usually 5am by that point), and the next day work on mockups and DB schemas if it still seems like a good idea.
Make a mockup in HTML/CSS or Photoshop/Fireworks, then show it to someone.
I use a Rails scaffold for a certain feature of the app (usually the simplest) and I build off of it. The generated code may change completely, but that's the point; it's just a scaffold to get me started so I can write the real code. If your framework of choice doesn't have that feature, you could try writing something similar yourself.
There's multiple point of entries! Just do it!
Define/Pick ONE core feature of your web application. Make that feature work, no one cares how you do it. Once you are finished with that core feature, use it as a base for all other new features.
An analogy, to create a sculpture of a head. First shape your clay into a ball, now you got your base feature.
Go get them Tiger!
Define/Pick ONE core feature of your web application. Make that feature work, no one cares how you do it. Once you are finished with that core feature, use it as a base for all other new features.
An analogy, to create a sculpture of a head. First shape your clay into a ball, now you got your base feature.
Go get them Tiger!
Check your ego at the door. Do some sketches. Have some conversations with friends and other people about the idea. Focus on initial reactions and gut feelings. Sleep on it. Wait a week. See if it's exciting after a week. Do some more paper prototypes. Sleep on it. Wait a week. Compare both sets of sketches. Focus on common elements. Write something down. Get advise from domain experts. Sleep on it. Wait a week. Have some potential users do some sketches. Compare with your sketches. Focus on common elements. Sketch some more. Learn Ruby or Python. If you don't know HTML / CSS use Photoshop and send it to a company like XHTMLIZED. Use Rails or Django. Host it in the Cloud, preferably with Engine Yard or Heroku. Use MySQL. NoSQL will come soon enough. Review all of your sketches. Test it. Ship it. Check your ego at the door.
1. Sketch & remove features (usually fit in a page or 2, 3) until I have something minimal. While sketching, I also figure out the main features and then the main db tables and methods/functions. Sometimes the sketch paper has some competitors there, ideas around how to make money, user experience notes etc... Often a little supersimple objectmodel or db scheme too. Always fits on 1 page.
1.5 Put that sketch on my "ideas" wall. Most ideas never make it. But for the ones that do:
2. Set up local domain mynewsite.peter, and optionally put codeigniter on it.
3. Put 1 or 2 html pages up.
4. Create a database table or two, code some functions that call it, and get something working.
Now I have something working, I iterate on it finetuning it for a while. And if I still like it, I might improve it a little and put it online for friends to play with. I've done projects that I launched but only ever used myself.
1.5 Put that sketch on my "ideas" wall. Most ideas never make it. But for the ones that do:
2. Set up local domain mynewsite.peter, and optionally put codeigniter on it.
3. Put 1 or 2 html pages up.
4. Create a database table or two, code some functions that call it, and get something working.
Now I have something working, I iterate on it finetuning it for a while. And if I still like it, I might improve it a little and put it online for friends to play with. I've done projects that I launched but only ever used myself.
mkdir projectdir; cd projectdir; git init; copy in my Ramaze app skeleton; git add .; git commit. For larger projects, I'd very early on enter tasks and milestones into Pivotal Tracker. Next steps: I crack open my editor and begin typing out the DB schema. Move on to ORM Models, and begin to get bare bones, undecorated views + controller methods. Not long after that will be page layout(s) and CSS. By then, the project should be well on its way, with some functionality that actually works as planned.
Usually with these things, once you have your idea, it's just a matter of filling in the blanks. To quote from the movie Amadeus: "The rest is just scribbling."
Usually with these things, once you have your idea, it's just a matter of filling in the blanks. To quote from the movie Amadeus: "The rest is just scribbling."
I come from a business background so for me, the first step is to have an idea. Then I start a very basic and simple business plan to go with it.
The business plan outlines how users will interact with the site and here is where I set milestones and dates on when things should be complete.
By making a business plan it helps me see what I need to do and about how long things will take.
Next I start with coding and database, since everything has been put into my business plan it is very straight forward.
One thing to note is the plan can change, and it does often. Stay focused and always set goals and milestones to keep yourself on track.
"If you fail to plan, you plan to fail."
The business plan outlines how users will interact with the site and here is where I set milestones and dates on when things should be complete.
By making a business plan it helps me see what I need to do and about how long things will take.
Next I start with coding and database, since everything has been put into my business plan it is very straight forward.
One thing to note is the plan can change, and it does often. Stay focused and always set goals and milestones to keep yourself on track.
"If you fail to plan, you plan to fail."
Find a potential customer and run the idea past him/her.
Figure out how to do the bit I don't know how to do. The rest of the application is mostly just stuff I know how to do and only need to make sure I do properly.
Figuring out how to do something is always more exciting to me than actually coding it, although normally the two can't be separated. Sometimes I need to implement a minimal framework first in order to have a setting to solve the problem.
Figuring out how to do something is always more exciting to me than actually coding it, although normally the two can't be separated. Sometimes I need to implement a minimal framework first in order to have a setting to solve the problem.
for me #1 thing is to use google to see how many searches are there a month for relevant keywords.
If you know that 18,100 people a month search for "website monitoring" you know that there is some market for it.
Then of course you gotta check for other competition on that keyword to make sure there isn't someone doing the same exact thing you plan to do
If you know that 18,100 people a month search for "website monitoring" you know that there is some market for it.
Then of course you gotta check for other competition on that keyword to make sure there isn't someone doing the same exact thing you plan to do
I always start with design.
Once you have a design, turn the design into html
Once you have the html, start building out the functions in the design.
Once you have a design, turn the design into html
Once you have the html, start building out the functions in the design.
I hate to market myself like this, but this seems like a good thread.
My startup is building something to super-simplify how you go from initial idea to final product, especially if you are not a programmer and still want to do it on your own. Drop me a note at harsh[at]zopte.com and I will send you an invite.
My startup is building something to super-simplify how you go from initial idea to final product, especially if you are not a programmer and still want to do it on your own. Drop me a note at harsh[at]zopte.com and I will send you an invite.
1. Idea
2. Sketch interfaces on paper
3. Code html/css interfaces in Rails
4. Extract DB schema from interface
5. Create models in Rails
6. Connect models to the interface with controllers
edit: formatting
2. Sketch interfaces on paper
3. Code html/css interfaces in Rails
4. Extract DB schema from interface
5. Create models in Rails
6. Connect models to the interface with controllers
edit: formatting
Yes this is always a mystery to me too. I am not a web developer. When I develop a web project there are always others who do it differently and better. I improved by some steps doing it the hard way, but it would be great to have some insight from people experienced in this.
In terms of starting actual development, rather than the whole process from conception onwards:
1. Define DB schema
2. Define URLs. I find this is the best way to figure out what bits I actually need to write
3. Solve any difficult/tricky bits first, even if just as a proof of concept
4. Implement the rest
1. Define DB schema
2. Define URLs. I find this is the best way to figure out what bits I actually need to write
3. Solve any difficult/tricky bits first, even if just as a proof of concept
4. Implement the rest
4.a) Implement REST
1) Idea
2) check market potential using google keyword tools and get an answer to the question: Can I make money with this?
3) If 2) ist positive, then write it down and go to 4) , if not, forget about it.
4) set workflow then mockup
5) code
6) SEO
7) try to get ramen profitable
2) check market potential using google keyword tools and get an answer to the question: Can I make money with this?
3) If 2) ist positive, then write it down and go to 4) , if not, forget about it.
4) set workflow then mockup
5) code
6) SEO
7) try to get ramen profitable
Find customers.
1. idea
2. list features in order of importance
3. select top 50% of 2.
4. paper mockup with various iterations
5. code
6. revise with external feedback (usability study?)
7. go to 3/4/5.
2. list features in order of importance
3. select top 50% of 2.
4. paper mockup with various iterations
5. code
6. revise with external feedback (usability study?)
7. go to 3/4/5.
1. idea
2. google the idea
3. html mockup
4. code
2. google the idea
3. html mockup
4. code
Or, my favorite:
1. idea x
2. google idea x, find nothing
3. spend 2 weeks working on it
4. realize your idea isn't actually x, but more like y.
5. google y, find a bunch of people have already implemented it.
1. idea x
2. google idea x, find nothing
3. spend 2 weeks working on it
4. realize your idea isn't actually x, but more like y.
5. google y, find a bunch of people have already implemented it.
[deleted]
6. So go back to doing x.
Brainstorm
Paper sketches
HTML + CSS mockup
Code
Just dive in, and start! Prototype, model, plan. Fake it until you make it, in other words.
After you have the initial idea, what's next? Start defining features? Draw up a mockup on a piece of paper? Start writing the DB schema?