 | Level: Introductory Nicholas Chase, President, Chase and Chase, Inc.
01 Mar 2003 In this second part of our series following the development of MetroSphere.com, Team Lead Nicholas Chase describes how the planning process will determine priorities and shape the project plan. Whether things will turn out exactly the way the team thinks they will is another story; the first rule of Web development, in the team's experience, is that a site is never quite what you thought it would be when you started out.
|
Editor's update
The Web site MetroSphere.com -- the online technical community discussed in this article -- is no longer live. However, the information and screen captures regarding the installation of IBM WebSphere Portal are still accurate and relevant.
|
|
MetroSphere MetroSphere is an online technical community and information marketplace built with WebSphere Portal. When it's complete, MetroSphere will allow consultants, programmers, and technical writers to gather and share information, tips, and techniques, while at the same time providing a customized portal to information of their choice. MetroSphere will be a place where individuals and companies sell and barter technical content and services, as well as enable better collaboration and workflow on new and existing projects. In this series of articles, tutorials, and tips from Studio B, we share our experiences as we build the MetroSphere portal. Planning is my favorite part of any project; it's the time when anything is possible and nothing has yet gone wrong. It was a number of weeks between the moment we decided to take on this project and the moment in which we were given the go-ahead to do it. A lot can happen in a few weeks of Web Time, and we used it to our advantage, taking the time to consider what we wanted and to think about all of those possibilities. We are a diverse group -- technical and non-technical. The main group includes business people, developers and administrators, and a graphic artist. Together, we let ideas flow and morph until they took on a shape that was manageable. They became, in the end, the core of MetroSphere.
Getting it together The first step in planning the MetroSphere project was to get together the Powers That Be and talk to them about what they wanted the site to be. We knew that we wanted the site to act as a marketplace for technical information, where authors could offer content in an electronic form for sale, but what else did we want? The next step, we knew, was to find a reason for users to come to the Web site. Ideally, they would come for the content being offered, but realistically, we knew we needed more. A site should seem to flow organically out of its purpose. If all we wanted was to sell e-documents, we could just set up an account with large booksellers on the Web. Instead we needed to determine what the nucleus of the idea really was. To start the process, we scheduled a brainstorming meeting. No possibility was considered too remote to explore -- we could always scale back to reality later. David, our boss, acting as the customer on this job, favored the information portal approach. He wanted to find not only content he was interested in, but also people who had similar interests. Even if he couldn't meet them personally (which he also wanted to do), he at least wanted to take advantage of whatever wisdom they were offering. He also wanted to gather together all of his daily news sojourns to get them all in one place. He wanted, he said, to come to MetroSphere and get his bearings on what was happening in his corner of the technological world. It seemed a reasonable request. We talked about ways to create a virtual clipping service, where users could keep up-to-date on topics of their choice, and about ways to feature information so that the larger gold nuggets didn't get buried. We talked about blogging. Eventually, we arrived at the core, at what the place was about.
MetroSphere: Where people, blogs, and news meet It's just a slogan, "Where people, blogs, and news meet," but it does more then just give potential users an idea of what MetroSphere is. More importantly, it gave us an idea of what it was so that we could both see if it matched what we had in mind, and could also start to plan for our users. In planning a site like this, you have to ask yourself some very basic questions:
- Who is your target audience?
- Why should they come to your site?
- Why do you want them to come to your site?
The simple answers -- "Everybody," "because we advertise it," and "because we want to make money" -- are, of course, completely inadequate, and explain a lot of the dot-bomb sites of the late 1990s. Taking time up-front to really answer these questions will point you in the right direction, saving time, pain, and heartache later. In our case, the answers were pretty straightforward. Who is your target audience? The target audience for MetroSphere are the producers and consumers of technical content and services. Our primary audience includes programmers, engineers, designers, and others who work in technical fields. In building any community, it's important to start with a fairly tight focus. You can always expand later, so we'll be starting in the field we know best: computers and the technologies that surround them. Our secondary (but just as important) audience consists of potential sellers: technical authors who have content to sell and, eventually, consultants offering their services. Why should they come to your site? This question is often interpreted as a marketing question, but it's actually about intent. Assuming you get users to come to your site, what would they want out of the experience? What information are they looking for? What functions are they trying to accomplish? David had articulated our users' primary objective: to get a bearing on the technological industries in which they are interested. We saw several secondary objectives, including locating specific information, finding users with similar interests, and creating a place, or a type of mini-site, a user could call his or her own. Why do you want them to come to your site? As weblogging grows in popularity, it's becoming less and less reasonable to say, "Nobody puts up a Web site for the heck of it," but from a business perspective, you must have a reason for attracting people to the site. Usually this reason is related to the site's revenue model -- a concept also forgotten in the dot-com boom -- but it could just as easily be related to providing a service to users, or to accomplishing some off-line goal. In any case, you want users to come to your site because you want them to DO something, whether it's to buy something, to get information online instead of clogging up your call center, or to simply enter their demographic information so that you have it for advertisers. In our case, we want people to create their own spaces, or dailies, so that they can provide guidance and information useful to other users. Eventually, we want them to buy and sell content and services.
Breaking it down Once we had all of this information, it was time to start breaking it down and prioritizing it so we could determine the pieces that we would build first. We'd decided early on that we'd start small, building in groups, or phases, each of which would be considered a major release. In order to decide what tasks would go into Phase 1, we used the Extreme Programming method of creating user stories. Similar to use cases referenced in other programming methodologies, user stories are short descriptions of things users should be able to do when they come to the site, such as "Sign up for an account," or "Add a comment." (In this case the term user also included administrators, since we'd have to create their functionality as well.) We already knew that we were going to be using IBM WebSphere Portal for the framework of the project, so I was able to give rough estimates of the amount of time each story should take to implement given what I understood about how Portal worked. From there, we were able to place relative values on each story and choose a manageable chunk for the first major release. (Smaller releases would be the order of business along the way, but we needed to decide on the final goal in order to manage customer expectations.) Phase 1, we decided, would concentrate on four areas: Weblogging If you've been trapped under heavy furniture for the last six months or so, weblogging, or blogging, is when a user creates a page on which he discusses interesting or useful sites or pages he has come across, usually providing commentary about the resource. Blogging can be journalistic, it can be objective and sparse, or it can be intensely personal. In any case, it serves as a counter-balance to the information overload so prevalent on the Web today. Rather than keeping up with everything, users can see what other people with similar interests are reading. There is no blogging component for Portal, so we will have to build one from scratch as a portlet application. Users will be able to post their own links, which will appear on the home page until superceded by more recent links. In addition to appearing on the home page, user entries will appear on the user's blog page, which the user can also customize to some extent. Users will be able to point other users to their blog, just as they could if the blog were hosted on a system such as Blogger. Later, we'll look at integratng with other blogging systems. Editorial content The major purpose of the Web site is to provide interesting and relevant information. Blogging provides part of this solution, but we still had two problems. First, with any luck we'd be swamped with entries and we wanted to be able to highlight some that seemed particularly interesting, and two, we wanted to be able to provide content that wasn't necessarily in the form of a blog entry. For example, an author might contribute an article on the nature of Extreme Programming or on federated data in DB2. We decided to create an editorial feature section in which topic editors could choose or create entries to separate from the rest of the pack. We considered storing them as documents in Domino, and eventually we'll probably go that route. For now, though, we decided to keep it simple -- Domino isn't part of the base WebSphere Portal Enable (Portal Enable) install -- and make the features part of the blogging application. Personal pages The purpose of the mini-sites in Phase 1 is to provide users with a place to showcase any information that they want, such as documents they want to make available. Users should have a great deal of control over the page and its content. One of the issues we wrestled with (and are still wrestling with) is how to manage external documents. We could easily instruct users to link to documents on another server, but ultimately, we want them to be able to control who has access to these documents using Portal's built-in permissions system. Again we run up against the fact that Domino isn't part of the base Portal Enable install, but Portal Enable itself does have rudimentary document-management capabilities in the form of the Content Organizer portlet. One of our first tasks will be to create a spike solution, or a proof-of-concept that determines the best way to handle these documents. Personalization and personal tastes Personalization in Portal is perhaps one of the most exciting of the features we're looking forward to using. Some personalization we're going to do ourselves. For example, the blogging application will give the user the ability to choose topics that should be shown by default. If I have no interest in a particular topic, I don't want to have my pages cluttered up with it. However, that's just the tip of the personalization iceberg. WebSphere Portal includes the LikeMinds Personalization engine. This means that we can set up the portal to automatically suggest material, such as entries, features, and documents, that a user might find interesting. Not only can we do that using specific rules, but we can also do it based on personal preferences. In other words, the portal can figure out who has tastes similar to mine as well as choose information they find interesting to suggest to me. Future items As much as we wanted to include everything, some features just didn't make the cut. The daily, or clipping service, will have to wait for the next phase, as will some of the other more exotic items we discussed in our brainstorming meetings. But we've got those user stories salted away, and as soon as we're done with Phase 1, they'll be waiting for us.
Summary The MetroSphere project will follow the creation of a technical community that will eventually evolve into an information marketplace. During Phase 1, articles, tutorials, and other content will follow the creation of the site, including installation, the building of an extensive blogging portlet application, editorial content, personal pages for users, and personalization using both custom programming and the personalization engine. At least, that's the plan. Stay tuned... The next article in this series will put experience to work, discussing the main steps in choosing a business pattern.
Resources
About the author | 
| | Nicholas Chase has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, and an Oracle instructor. Recently, he was the Chief Technology Officer for Site Dynamics Interactive Communications in Clearwater, FL, and is the author of three books on Web development, including Java and XML From Scratch (Que). |
Rate this page
| |
