So personal projects are all about learning but if you want to do things fast and you have the option to, then stick to what you know
Sparkabout is a travel site Simon and I are working on, I tried to build it twice as my first django project but I ended up reengineering and over-engineering it so much, particularly the data models
when Simon and i worked on it together then we got the django end mostly there in a weekend, it wasnt beautifully optimised but that wasn't the point
This is liquid fold a stats app for aggregating the viewport size of your users
we built it on google app-engine because we were worried about scalability
but it turns out the one thing that google cant do is count
apengine doesnt do counters that scale, which is kinda important for a stats package so we never really launched it
it is a good idea to spin parts of your project into reusable components and open source them
it will be useful for you in later projects as well as
encouraging you to write reusable modular code now
and if you are really lucky someone will improve it foe you because you open sourced it
The most important question you can ask at the start of a project is where does the data come from
data doesn't just grow on trees
its no goof saying you will just add the data later because the data is the core of your site or application
and as such your data is coming from users you need to put a lot of effort into making it easy fun and worthwhile
Wildlifenearyou has a whole bunch of code that will never see the light of day because we hadn't decided where the data was coming from before we built the feature, for example exercises for kids to do at zoos
When you launch an interactive site it is essential to have an insight as to what people are actually doing with it
activity feeds are simple to implement and a great way of doing this. you can also tail your log files if you are that way inclined
your activity feed doesn't have to look good its really only for you to look at.
For example our feed for wildlife near you shows when anyone uploads a photo, suggests a species or creates a trip
one of the things with a personal project is you now have a responsibility, its like a pet
if you are taking user accounts you need to look after your users probably long after you have lost interest in the project
a good example of this is djangopeople desperately needs a delete your account function.
it seams counter intuitive but the people who want it REALLY want it. we get about three requests a month and have to do it manually
you have to consider is the hype caused by scarcity and demand really worth it?
you are putting a barrier in front of people who genuinely want to use your site
people wont crash the site, scaling is not impossible now because hardware is cheap hardware is cheep, if we had done walrss now rather than then it would have been a different story
invitation codes take a lot of development and UX to be done right and done wrong can be terrible
It is very easy to go down rabbit holes of over complication
this is the opening hours entry form for a place on wildlife near you
we spent hours arguing over the data model on the fort, where in hindsight a simple textarea may have been better
remember you can release a rubbish feature and people will use it, you can learn from that and improve it later
we soft launched the site to friends about the same time simons talk from django con was released
also to note some of the first requests you get will be a german language version we have had about 3 of these requests already and we have only been live a week,
When we launched djangopeople it initially didn't have openid or microformats and Simon and I got quite a bit of stick for that. I was worried the same thing would happen with wildlifenearyou
On the fort I had crippling RSI and had to conduct three people with little experience of front-end. Consequently ever since then I have been working with legacy code but thankfully no-one cared.
It's really hard not to correct behaviour. Particularly if it is your own parents.
Parents make a great test case so instead try to find out what they were intending to do and why they did it this way.
Here my mum has labelled the species in this photo as a Simon and a 'don't pick up the penguin sign' which while amusing isn't really the intended use.
Play is good, its a sign of success when people are having fun with your site.
Except if they are intentionally trying to be disruptive and adding frozen chickens to your wildlife spotting site.
Here this user has added New York wherehe saw a cockroach and a madagascan hissing cockroach and a rat.
Your users should have the smallest possible barrier to entry for getting in touch with you,
This will make it more likely they'l use it and you wont have to guess if they like it or not.
The user only sees a box and a button if they are logged in because it is integrated into our site. we also store their username, email, ip, user agent and what page they are on.
dont worry about spam
because it is ajax people won't worry about sending you feedback midway through a form submission.
in the database we also have notes and status for us
You'll need to watch the data people enter into your site, if you are getting bad data it is a symptom of a problem with your design somewhere.
on django people, users didnt know they could move the map, we found this out because people said they lived in the sea.
on wildlifenearyou and innaccurate data points and duplicates, because our add trip and add place workflow needs work.
Shortly after we launched Simon and I discovered a similar site with more funding, while we were initially concerned we then realised they didnt have our same sense of fun and wasnt the same niche.
competition makes you reassess your goals and strengths and focus on what's important