

Ask YC:How do you create a website? - yearsinrock

Does the person having an idea create the new website around his own needs(such website never existed so i'll create one so i'll get around my time on the internet more efficiently) or is the build more concerned with the future visitors the site expects?<p>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?<p>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?
======
mechanical_fish
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!

------
josefresco
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
;)

------
prateekdayal
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 :)

~~~
omfut
Thats a nice site you have built. How are u working out the RIAA issues?

------
ryanmahoski
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!

------
neovive
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.

------
ALee
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.

------
tel
In a text editor.

People don't want websites, though. They want services, products, information.
The creation of those is a debated topic.

------
mynameishere
You expect someone to explain web application engineering in this comment
section?

~~~
mechanical_fish
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. ;)

~~~
blogimus
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.) "

------
TweedHeads
First go to <http://www.designmeltdown.com> and get the best of the best.

Then copy, change, polish and release.

Presto.

Profit!

