by Scott on June 22, 2007
It’s an impressive speaker line up at the Business of Software Conference, October 29th and 30th in San Jose. Scheduled to speak: Guy Kawasaki, Joel Spolsky, Eric Sink, Rick Chapman, Bill Buxton, Jeffrey Pfeffer, Hugh MacLeod, Dan Nunan, Tim Lister, Jennifer Aaker and others to be announced.
In the words of organizer Neil Davidson:In October 1999 Simon Galbraith and I [Neil] set up Red Gate Software. Over the past 8 years we’ve grown from 2 people to almost 100. Although we have had our successes, we’ve also made plenty of mistakes. The people who I’ve invited to speak at Business of Software 2007 are world-class thinkers, doers, writers and speakers who I wish I’d heard of earlier, and listened to more. I’m hoping that by bringing them together in one place, over two days, we will all learn how to set up, grow and run our businesses better.
Sign up for their mailing list here and you’ll get a free 319 page e-book:Eric Sink’s ‘Business of Software’.
[0]
comments
by Scott on June 21, 2007
Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article I share why, despite best attempts by the anti-paperwork crowd, I like written use cases.
Use cases:
- Contribute directly to the final, deployed app.
- Expose risks to simplicity.
- Expose the level of development work required.
- Are the easiest way to iterate, collaborate and communicate.
Use Cases
Briefly put: a use case can be anything that documents how a person will accomplish a task with your application and how the application will respond. In this article I use the term to mean written use cases (as opposed to diagrams or sketches).
Click here for an example.
Some developers do not write use cases because doing so feels too much like writing documentation and documentation is not the purpose of building a system. So, in an effort to work only on things that directly contribute to building the app, people skip over the use case step and jump right to visual design or sketches (or even just start hacking out code). I have to say that back in my developer-only days, I was that way too. I saw anything but code as wasted time. Now, I don’t. Here are four reasons why I don’t skip the use case step.
Read more...
Posted in Making of a web app, Programming, Web Application Design, Make a Web App
[2]
comments
by Scott on June 19, 2007
Money, get away.
Get a good job with good pay and you’re okay.
Money, its a gas.
Grab that cash with both hands and make a stash.
New car, caviar, four star daydream, Think I’ll buy me a football team.
Everyone, sing it with me:
New box, database, VP daydream, Think I’ll buy me an IT team.
Money
In Making of a Web App I said that new software projects should simplify scope for increased likelyhood of success, greater end-user satisfaction, and key stakeholders who get what they need instead of a version diluted by dozens of others’ desires.
Yet, on large projects with dozens of stakeholders – such as is common on corporate IT efforts – it’s impossible to effectively reduce and simplify. There are decades of project management best practices and strategies for helping large, complex projects succeed. This post is a warning to those new to the industry and new to corporate IT efforts: don’t try reduce and simplify at your office. It won’t work. And here’s why.
Read more...
no trackbacks
[0]
comments
by Scott on June 18, 2007
Making of a Web App is Synap Software’s step-by-step look at designing and developing a web app. In this article we get a little bit ahead of ourselves and talk about styleguides.
Early PlaybookIQ Styleguide decisions:
- Use of the International Style
- Tab-based navigation
- Persistent search box
Read more...
Posted in Making of a web app, Synap Software: Design Decisions, Make a Web App | 7 trackbacks
[0]
comments
by Scott on June 18, 2007
I love this photo – “Understanding how to use a remote is made easier by a friend” – as an example of the power of reduction to make something easier to understand and give people a better experience. Take away all the stuff people don’t need and suddenly instead of fumbling around feeling stupid, they easily start doing what they want.
Also, the instructions are written directly on the remotes. The friend didn’t write seperate notes on a piece of paper saying “press the up and down arrows on the slim remote to change volume”. Instead, the friend wrote directly on the remote: “Volume”. Similarly, seperate “help” files and manuals for software need to die. There are better alternatives such as inline prompts and making a design so obvious and activity-centered that people do not need help files.
Posted in Simplicity, Web Application Design | 6 trackbacks
[0]
comments
