Claude Ritter

Web 3.0 and Semantic Web

Posted by claude - 25/02/08 at 01:02:29 pm

Ever since Tim O’Reilly coined the term Web 2.0 people have been asking what Web 3.0 is going to be. A lot has been written about this topic and it looks like there is some sort of consensus about what Web 3.0 will be. Semantic Web.

The interesting thing with Semantic Web is, that the technology has been around quite a while. Back in 2002 Edd Dumbill published an article titled “Finding friends with XML and RDF”, which basically describes what we call the Social Graph today (see Google’s Social Graph API). This is somehow similar to the evolution of Web 2.0 with its user-generated content. Long before we even called this Web 2.0 we had bulletin board systems, dating communities, marketplaces and much more. Due to a growing online population, technological progress, falling prices and other factors, companies were able to leverage existing technologies and build new services on top/around them.

As I mentioned above, the underlying technology needed to add a semantic layer to the Internet is not really new. The two basic building blocks or core technologies are the Resource Description Framework (RDF) and Xhtml Friends Network (XFN).

What’s missing?
RDF, XFN and other technologies related to the Semantic Web are difficult to understand. While there are projects such as Microformats or The Friend of a Friend (FOAF) project aiming at making things easier, we are still far away from having a mainstream Semantic Web application. In order to bring it to the masses, these technologies need to be implemented in the tools people use for their daily work. What I mean is that it must be transparent for the users so that there’s no need to bother about RDF etc. while using blog software, a social network or the web mail client.

Will there be ONE big Semantic Web company?
Due to the distributed nature of the Semantic Web I don’t think that there will be one company or service dominating this space. We will have thousands of blogs, social networking websites, discussion boards and other services participating in creating the Semantic Web. Users will get used to the fact that their information is shared between several services and that they are able to access their friends everywhere. Therefore the ability to share information between different services and websites will become a key success factor for all “social” services in the future. Semantic Web is part of the product, not the product itself.
A very interesting service, which is definitely worth watching, is Twine. From what I can see now, it looks like a social network built on top of a Semantic Web application, which also contains a friend aggregator such as Friend Feed. So far they are doing a good job in hiding the complex technology and making it understandable for consumers.

Why you should let users define your app, sometimes

Posted by claude - 18/02/08 at 02:02:14 pm

ReadWriteWeb has an interesting post titled “Why You Should Let Users Define Your App“, written by Josh Catone. First I have to say that I generally agree with that statement but I feel that some things have been mixed up in this article.

To explain my point I need to reach back a bit. Most businesses, be it online or offline, have to generate revenue in order to operate and grow. This is the case with our company. We operate a bunch of community websites and generate revenue with a mix of advertising and premium services (Freemium Business Model). Our company did not take VC money until know and is running profitable since the beginning. I said “most businesses” above because a startup could also try to get some external investment, grow as fast as possible and then look for an exit. I am not saying that’s wrong but it’s something to keep in mind when reading the post I linked above.

Josh mentioned Twitter as an example. Twitter is running with VC money and is trying to expand its userbase as fast as they can. Eventually they will become some sort of “Internet Messaging Bus”, people and applications will depend on it to a degree that they can’t live without it. And then, Twitter will be sold.

Seesmic, Loic Le Meur’s new startup, also heavily uses crowd-sourced product planning. Without knowing their strategy I would guess that they have a pretty similar approach like Twitter. Do what the users want, get as many users in as possible and then sell the company. Therefore new features don’t have to support the business directly by generating revenue but are built to attract new users.

Another example mentioned in the article is the game industry. User driven development has been practiced quite a while in the gaming industry and I think that it’s the only way to develop games that people really want to play. But, there is a big difference between services such das Twitter and games. Games are actually SOLD, for real money.

I said that I agree with the fact that you have to listen to your customer. But the approach to simply do what the user wants, won’t work in every case. The two examples from ReadWriteWeb are very different and don’t represent the majority of companies or startups out there. So, unless you have a world changing idea with first mover advantage, a profound business strategy is still the key to a successful company.

Sprint Planning Meeting Impressions

Posted by claude - 13/02/08 at 10:02:50 am

Except from nice looking illustrations and graphics there was not much we could find when we were looking for teams holding daily standup meetings, planning meetings etc. Because of that I thought that it might be interesting to see how a sprint planning meeting looks in real life at The NetCircle.

So here’s one of our teams doing a sprint planning meeting.

And again, with Scrum Master at work.

These pictures were taken while the team was selecting the user stories for the next sprint.

Getting things done with To-Do Lists

Posted by claude - 12/02/08 at 05:02:59 pm

Over the past months I was reading several articles about being more productive with to-do lists. While I understood the purpose of having to-do or task lists in projects I did not get the reason why there would be the need to work with personal to-do lists. Plus, as I was anyway working with Outlook calendar to schedule all the meetings it seemed somehow useless to maintain another list in parallel. However, as my tasks kept piling up it started to make sense to organize them or at least write them down.

Outlook appointments are not tasks on a to-do list

There is nothing wrong with using Outlook or some similar program to schedule appointments, vacations or the golf round in the evening. But, appointments in Outlook are not tasks on a to-do list. In fact tasks are either a result of some appointment, need to be completed before or both.

What’s a to-do list and what are tasks?

There are plenty of very good articles, blog posts and books about to-do lists and tasks so I will focus on the way I work with them.

My key points for to-do lists

• Keep it current. On Monday, I create a to-do list for every day of the week. Then I focus on Monday’s list and fill it with stuff that’s on my mind (it’s allowed to add tasks during the day). The goal is to complete all tasks before the end of the day. If one task could not be completed, move it to the next day.
• Fun and easy to use. To-do lists can be done in many different ways. You could use Notepad, Outlook, Excel, a piece of paper, the mobile phone etc. My favorite to-do list and the tool I use is Ta-da list. It’s a simple web app and it’s actually fun to use. There are not deadlines, reminder fields and tasks are either done or not.
• Do it. This sounds a bit silly but now and then I am tempted not to do a list for one day because I feel there is no time for it. The result is stress and the feeling that you’ve forgotten something.

Key points of a task or a to-do

• It’s a physical action. Formulating my tasks in the form of a physical action makes sure that I thought about how I am actually going to complete a task. It also helps to prevent me from writing down pseudo-tasks which lie somewhere in the future and are never going to be completed anyway (“Plan networking lunch…”).
• Keep them small. Tasks should not contain sub-tasks. I try to be as granular as possible to make sure tasks can be completed as a single entity.
• Keep the syntax. Most of my tasks follow the same syntax. Some examples: “Call Angela to schedule Feedback Meeting”, “Request project reporting from Ben”. Do not add tasks like “Birthday party”.

Adding tasks to a list also helps my to find out whether I am the right person to do that tasks or whether I should delegate it.

As I mentioned above, there are many good resources for you to read about to-do lists and there are even more ways how to work with them. The above is my way of doing it and I can’t guarantee that it’s working for you. There is no wrong way, just try it.

Scrum, first impressions and learnings

Posted by claude - 12/02/08 at 01:02:21 am

So, this is my first post on my new blog. I am not going to write an “About me” like first post. There’s an about page which gives you some information about me.

At the end of 2007, we realized that our company have to change our development process. We were still working with some kind of waterfall model and we felt that this does not suit our needs. All of our projects are web based with some sort of social networking or dating community. Running high traffic community sites requires rapid development, flexible product planning and the ability to change or improve fast. Our traditional approach just did not work anymore and resulted in tons of specifications which had to be re-written all the time or became obsolete due to changes.

While evaluating different methods and processes we came across Scrum. Below is a short explanation of what Scrum is (from Control Chaos):
“Scrum is an Agile process that can be used to manage and control
complex software and product development using iterative, incremental
practices.”

The Wikipedia article is a good starting point should you not be familiar with Scrum.

When we decided to try with Scrum, nobody at the company had any experience with it. So the first phase was about learning Scrum and reading as much as possible about it. At this point I would like to recommend a book from Henrik Kniberg. His book is called Scrum And XP from the trenches (PDF) and is an excellent description about real world work with Scrum.

After some time of research one of our teams started using Scrum and just finished the first sprint last week. I personally did not expect too much from this first sprint but to my pleasant surprise, the results were amazing. In 15 days, the team managed to complete almost all of the user stories which they selected in the sprint planning meeting. Of course, this was the team’s first sprint and the first Scrum sprint in the whole company which means there is lots of room for improvement.

Here are some learnings:

• Define the word ‘Done’. Scrum is all about finishing things in a specified time. In order to achieve this, you have to define what you mean with finishes/done and make sure the team understands it. While this sounds easy in theory, it’s not in practice. Define whether your definitions of ‘Done’ includes testing, copywriting, styling etc.
• Don’t try to be perfect. Especially when you are going to start Scrum without having experience with it. Many things might be new to your developers so don’t expect that everything will run perfect right from the start. Scrum does not solve problems for you, it makes them visible.
• Have a Sprint Goal. A sprint is a intensive experience and it helps when everybody works towards a common goal. A Sprint Goal helps your team to focus on what’s necessary to complete the sprint successfully.

I will continue writing about Scrum as our journey continues. We we’ll have another team starting with Scrum soon and I am looking forward to telling you more about our progress. In the meantime, if you are interested, check Hendrik’s book (PDF).

Search