Ask YC:How do you create a website?
9 comments
You're mixing up a couple of questions here. One is "should I build just a minimum set of features and then add features slowly, or should I first draw up a design that includes every single feature I think we might eventually want?" The other is "should I build a site that works well for only one user -- probably myself -- or should I design with the assumption that there will be a lot of future users?"
These are important and controversial questions with answers that depend on the circumstances. The general approach advocated around here tends to be "start small; don't build things you aren't sure you're going to need; launch your site as fast as you can with the minimum number of features and don't build more until you're sure that users are interested and that they want more." But that approach is tuned for certain problems -- specifically, it's tuned for bootstrapped startups that are exploring new classes of application that might or might not have a market. One might argue (I would) that the majority of problems are well suited to that strategy, but no doubt there are some problems where other strategies are more appropriate. (e.g. you're designing a site for the Olympic Games, which will have relatively few users for months, then have thousands of hits per second for two killer weeks, then have a much smaller number of users going forward. You're not going to get to iterate the design over and over after the Olympic opening ceremonies; you have to plan ahead and build all the features you want, in a scalable fashion, in advance.)
Your question is related to the problem of categorizing software development processes. You might want to check out these two links for a start:
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Scrum_(development)
Or, if you have an idea for a website, you might be better off skipping all this management-class stuff, learning some HTML and/or PHP or Ruby, and putting a site up! Design it just for yourself! Don't put in more than one button at a time!
These are important and controversial questions with answers that depend on the circumstances. The general approach advocated around here tends to be "start small; don't build things you aren't sure you're going to need; launch your site as fast as you can with the minimum number of features and don't build more until you're sure that users are interested and that they want more." But that approach is tuned for certain problems -- specifically, it's tuned for bootstrapped startups that are exploring new classes of application that might or might not have a market. One might argue (I would) that the majority of problems are well suited to that strategy, but no doubt there are some problems where other strategies are more appropriate. (e.g. you're designing a site for the Olympic Games, which will have relatively few users for months, then have thousands of hits per second for two killer weeks, then have a much smaller number of users going forward. You're not going to get to iterate the design over and over after the Olympic opening ceremonies; you have to plan ahead and build all the features you want, in a scalable fashion, in advance.)
Your question is related to the problem of categorizing software development processes. You might want to check out these two links for a start:
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Scrum_(development)
Or, if you have an idea for a website, you might be better off skipping all this management-class stuff, learning some HTML and/or PHP or Ruby, and putting a site up! Design it just for yourself! Don't put in more than one button at a time!
You can't plan for hypothetical future visitors with unknown needs and wants.
Design and build your idea based on your research and if/when you survive the first 6 months, then start to add features requested by your community (and thank whatever almighty you believe in that you do in fact have a community)
Now, if some VC dumps a bunch of money on you, then by all means throw in everything but the kitchen sink and burn, burn, burn that cash until you exit ;)
Design and build your idea based on your research and if/when you survive the first 6 months, then start to add features requested by your community (and thank whatever almighty you believe in that you do in fact have a community)
Now, if some VC dumps a bunch of money on you, then by all means throw in everything but the kitchen sink and burn, burn, burn that cash until you exit ;)
I will tell you what I have learnt in one year of running http://www.muziboo.com
1. Start small but do those small things right. Think of how new people will come to your site. If you are a content site, the chances are SEO, so think of it from day one.
2. Listen to your users and build what they want. Sometimes bloggers and press don't exactly know the needs of your users (unless you are building feedburner)
Keep tracking everything and see what works and what does not and then base your future work on it. Try to spread faster than word of mouth :)
1. Start small but do those small things right. Think of how new people will come to your site. If you are a content site, the chances are SEO, so think of it from day one.
2. Listen to your users and build what they want. Sometimes bloggers and press don't exactly know the needs of your users (unless you are building feedburner)
Keep tracking everything and see what works and what does not and then base your future work on it. Try to spread faster than word of mouth :)
Thats a nice site you have built. How are u working out the RIAA issues?
First, ask yourself "What do I want from this web site?" Let your answer to this question drive your design. Before you even get into the html, brainstorm. Let your imagination go. Write your thoughts down, sketch it out. Then consider how to build it.
The first step for me is a wireframe. That's just a drawing of how the main blocks will be laid out. Read Michael Parkatti's post: http://www.socialbias.com/the-case-for-building-wireframes/. Michael makes a strong argument for wireframing and reading it helped me understand my own struggle with design.
Next, build the wireframe. You drew it, now build it. Write the html and css to mimic your picture.
The next stage is filling in those boxes. You can start with the hard stuff but I prefer to crank out the easy stuff first. My goal is not to make the site beautiful (yet), just pretty enough to help me see some context.
As for the hard stuff, it depends on what you're trying to build. Digg took lots of talented people a lot of time. Make sure if you have your sights set high that there isn't a known "clone" that you can borrow as a template. Otherwise get used to learning scripting languages and frameworks. Good luck!
The first step for me is a wireframe. That's just a drawing of how the main blocks will be laid out. Read Michael Parkatti's post: http://www.socialbias.com/the-case-for-building-wireframes/. Michael makes a strong argument for wireframing and reading it helped me understand my own struggle with design.
Next, build the wireframe. You drew it, now build it. Write the html and css to mimic your picture.
The next stage is filling in those boxes. You can start with the hard stuff but I prefer to crank out the easy stuff first. My goal is not to make the site beautiful (yet), just pretty enough to help me see some context.
As for the hard stuff, it depends on what you're trying to build. Digg took lots of talented people a lot of time. Make sure if you have your sights set high that there isn't a known "clone" that you can borrow as a template. Otherwise get used to learning scripting languages and frameworks. Good luck!
When starting a new website or any business, I think the most important part is being passionate about the product or service you are trying to sell or the problem you are trying to solve. Usually, being passionate about something, means it is closely related to your own needs.
Approaches to building the actual website vary greatly. Some people prefer writing detailed specs first, while others prefer a prototyping approach -- to start working with a tangible product sooner and get feedback early. I prefer the prototyping approach for new websites.
When you start the actual development, focus on the core elements first (e.g. Digg couldn't function without it's core news algorithms and digg tracking, but did not need other peripheral features to move forward). I also like to work out my database design and user interface (screen mockups) early in the process. 37Signals recommends rough sketches and HTML mockups at the outset in their "Getting Real" book. After a few projects, you will likely have your own optimal approach that works well for you.
Approaches to building the actual website vary greatly. Some people prefer writing detailed specs first, while others prefer a prototyping approach -- to start working with a tangible product sooner and get feedback early. I prefer the prototyping approach for new websites.
When you start the actual development, focus on the core elements first (e.g. Digg couldn't function without it's core news algorithms and digg tracking, but did not need other peripheral features to move forward). I also like to work out my database design and user interface (screen mockups) early in the process. 37Signals recommends rough sketches and HTML mockups at the outset in their "Getting Real" book. After a few projects, you will likely have your own optimal approach that works well for you.
MINIMUM VALID TEST
You start with the idea, find the assumptions in the idea (of why it's useful), you create a product that tests those assumptions, then adjust accordingly.
Plan, yes, but don't put way too many stupid features that don't matter. Your users as a whole are smarter than you and the market will tell you what to focus on. Create the minimum valid test.
You start with the idea, find the assumptions in the idea (of why it's useful), you create a product that tests those assumptions, then adjust accordingly.
Plan, yes, but don't put way too many stupid features that don't matter. Your users as a whole are smarter than you and the market will tell you what to focus on. Create the minimum valid test.
In a text editor.
People don't want websites, though. They want services, products, information. The creation of those is a debated topic.
People don't want websites, though. They want services, products, information. The creation of those is a debated topic.
You expect someone to explain web application engineering in this comment section?
Sure. Behold the miracle of hypertext:
http://philip.greenspun.com/panda/
Rather dated now, but the basics are still the basics. For somewhat newer material (but geared toward comp sci students):
http://philip.greenspun.com/seia/?
There. The rest is detail. ;)
http://philip.greenspun.com/panda/
Rather dated now, but the basics are still the basics. For somewhat newer material (but geared toward comp sci students):
http://philip.greenspun.com/seia/?
There. The rest is detail. ;)
I find this little passage (from chapter 1 of your "panda" link) is a good bit of wisdom that is just as true today as when he wrote it:
"People come to Web sites looking to get a job done or a question answered. The first thing the guys at www.fedex.com did was publish a Web interface to their package tracking database. That was back in 1994. When they decided to add corporate information they put it on an entirely separate site: www.fdxcorp.com. (Today the sites are merged.) "
"People come to Web sites looking to get a job done or a question answered. The first thing the guys at www.fedex.com did was publish a Web interface to their package tracking database. That was back in 1994. When they decided to add corporate information they put it on an entirely separate site: www.fdxcorp.com. (Today the sites are merged.) "
Still the best place to start.
First go to http://www.designmeltdown.com and get the best of the best.
Then copy, change, polish and release.
Presto.
Profit!
Then copy, change, polish and release.
Presto.
Profit!
Also,how does one start on building the website:does he create the main purpose fulfilling html elements first and then the other elements? or the systematic planned future approach?
For eg.If you were creating digg.com what would you create first the submit new url button and view the most popular and then add the other elements as time passes. or you would first the plan the whole page layout(as in final design)and then build the whole thing like categories at the top,sign in button,user pages (the way the elements appear from top to bottom on a page?