Designing a custom groupware application requires close interaction and open communication between developers and end users in all phases of the project. Because many people use groupware applications in many different ways—incorporating workflow, routing, and teamwork—the applications need to be designed from the various perspectives of each user. Each user has a different job to perform, different technical skills, and preferred interfaces, so including all groups of users that will interact with the application in the iterative process of design, coding, and testing is imperative. Involve the users right from the beginning and treat them as the customer. In this article, we outline the general steps to create a groupware application and concentrate, using an example, on the discovery and design phases.
General Steps to Create a Groupware Application
We wrote these steps from the perspective of a consultant, but the same process applies for in-house development. The example we use is a collaborative Web site, where people from every department in a company can update and create Web pages, all with a common look and feel and a stringent approval process.
1. Define the goal and scope of the application. Work with the client to determine the overall scope of the project. A fresh point of view often refines this process (even if clients think they know exactly what they want). Dig to get to the “pain”—if there is no problem to solve or pain to ease, there is no project.
2. Develop rough estimates of time and resources required to achieve the goal. Choose the tools that best meet the needs of the project and that fit into the current environment. Consider the time requirements for the discovery process, technical planning (hardware and software), development, testing, project management, documentation, and training.
3. Determine the business value. Is this a new application, or is an old process being replaced? What will it save in terms of workload, outsourcing costs, and productivity? What will it add in terms of revenue or new business or marketing value? Calculate the return on investment (ROI) by comparing the business value to the estimated cost of the project.
4. Perform discovery process/requirements analysis. This is one of the most important aspects of development and usually is not given enough consideration. Gathering detailed requirements and conducting end user interviews will minimize continuous changes during the actual development and help keep the project on track in terms of time and budget.
5. Create the design document. This is putting on paper the information you gathered during the discovery process and determining timelines, milestones, and delivery dates.
6. Develop the application. Use the design document to create the code, continuously meeting with users to stay on track.
7. Test the application. First, the developer tests it, then a tester, and then the entire group tests a prototype. When the application passes all required tests, coding is frozen and moved into a release. If requirements are discovered during testing, use a carefully monitored change management process to control time and costs.
8. Document the application. Ideally done by a technical writer, documentation should be developed for everyone so that they are able to more efficiently use and maintain the application. Documentation supplements training and serves as a reference source for future application users.
9. Train the users. Training must be provided for all users. A base of well-trained users will be efficient and involved in the future releases of the application and will serve as trainers for future users.
10. Support. Put in place a maintenance agreement for modifications, phone support, and bug fixing. The agreement, which makes clear the responsibilities of both users and developers, can be in place for a certain number of hours or over a certain amount of time.
The FlapJack Franchise
Traditionally, a Webmaster or team of Web developers manages the layout, administration, maintenance, and content of a Web site. Some companies also have marketing departments or content managers but may not have an efficient way for the two groups to get the right content on the Web site in a timely manner. A lot of cut and paste is involved, and a lot of good ideas don’t materialize because of a lack of resources. Teams on both sides get frustrated. The technical people don’t have the time or expertise to manage the content, and the people creating the content don’t have a good way to get their information on the Web site. Also, content should really come from everyone in the company; good Web content often comes from areas you least expect. Marketing doesn’t need to supply it all. For example, can human resources maintain the recruiting and job posting pages? Can customer service maintain product help documentation?
Take a look at a hypothetical company called the FlapJack Franchise, an international franchise with locations all over the world that decided to embark on developing and posting a Web site.
The Scope of the Battle
The company needed a Web site to distribute information to users and customers. It needed to make available operations information; calendars; contact information to franchise managers; and product, promotions, and events information to the general public. People with varying levels of technical skills, different browser types, and different modem speeds needed to access the site, so the requirement was to keep pages at the lowest common denominator. That dictated the inclusion of only a few small graphics and pages that are primarily text-based, with no JavaScript, Java, or proprietary technologies.
The company had been outsourcing the Web site to a third-party Web development company (the pain). Turnaround on content changes was slow. Bottlenecks occurred
during the time it took to get the new content approved, send it over to the third-party company, and wait for the work to get done. When it was complete, FlapJack would have to check to make sure that the changes were correct. Language barriers and translation issues were a challenge in some non-English-speaking locations. On top of that, the company was paying very large Web hosting fees. FlapJack wanted more control over the process, more control over the content, and a more streamlined approval process, so the company decided to bring the process in-house.
The War Room
Because FlapJack had an existing AS/400 infrastructure and had already implemented Lotus Notes for messaging, the development team decided to use a Domino/Notes platform to develop this application.
To come up with a rough estimate of the time and resources required, they broke down the project into the infrastructure and development components and estimated each part individually. The team then wrote a document summarizing this information for budget approval and as a starting point for planning a schedule, as shown in Figure 1.
To determine the ROI for this application, FlapJack compared specifically the value it was getting for the large Web hosting fee it paid each month to what it would get from doing the project in-house. Other determining factors to calculate the business value included the much faster turnaround time for changes, the higher degree of control of content, the better content (because it came directly from people motivated to keep it updated and correct), the increased security, the continuous updates (making all the pages dynamic and useful to customers), the in-house skills development, the ownership, and the pride for franchise location personnel.
Once the business value of the project was determined and presented to the corporation, it was easy to get the full support needed from management for the project to be a success.
Determining the Course of Action
To begin the discovery process, the development team held meetings with management, users at the corporate and franchise levels, and sample audiences in the various franchise locations. They created an internal discussion database so that users could comment on requirements and respond to comments of others on their own time. The open communication and the discussion database were instrumental in coming to these conclusions:
• A main corporate Web page with company information would link to each of the franchise locations’ Web pages.
• Each franchise location operated independently and needed to have its own “main page.” Each franchise location needed to maintain its own content. This was important not only for currency and relevancy to the franchise but also to make sure that the translation to the local language was correct.
• A consistent page layout structure needed to be maintained throughout every franchise site to capture brand recognition and consistency.
• All new pages on every site needed to go through an approval process before they were published to the Web site. Marketing and management would review content (correctness of information) and style (grammar, spelling, text layout, and graphics) and make final approvals. The approval process needed to involve different people for each franchise.
• Updates and changes to existing pages also needed to be approved before being published to the Web.
• People with varying levels of technical skills and Web knowledge would need to create the pages; simple forms with pull-down lists and text fields would be used so the people creating the pages would not be required to know any HTML or proprietary
scripting languages. Pages would be created through the Notes client, which all users were already familiar with.
• Old versions of some (but not all) Web pages needed to be archived for legal and business purposes.
• The company needed an intranet site that employees could use to access private company information, download forms provided by human resources, and communicate with other employees.
From this list, the team decided that a Web site template would be used to create each local franchise site. An additional Web site would be created for the main “umbrella”—the franchise as a whole—which would serve as the primary main page for the company and have links to each franchise’s Web page.
Refining the Strategy
The team developed the design document based on the information gathered in the discovery process. This document included flowcharts of how the page approval process should work, diagrams of the network infrastructure and site structure, and detailed information on what fields and functions should be available on each page. It also included a timeline for the development and deployment process, including milestones, deadlines, meeting dates, and status report dates. Figure 2 shows a workflow process diagram for creating a new Web page. Figure 3 shows a workflow process diagram for modifying an existing Web page, and Figure 4 shows a diagram of the overall site structure.
The team presented this document to the company for review to verify that communication had been clear and all parties involved were well aware of the project scope.
Using the design document, coding the components was fairly straightforward. First, the team discussed page layout concepts and determined an overall page layout design for each section of the site. Then, the workflow for the approval processes was coded. At various points during the development phase, more client meetings occurred to review small steps in development. This kept the client involved and ensured satisfaction.
Deploying the Troops
The company assigned committees for content approval and style approval and chose a test group of users from the corporate office and the franchise offices to begin testing. A test group of audience members was also chosen. The test diagram in Figure 5 was used.
The development documented the application in a standalone database, which was linked to the other site databases so that all users at the corporate or franchise level could access the most current help information easily. The documents were categorized and indexed. The team showed examples of franchise pages to spark ideas for new users. They also documented guidelines for creating graphics for the Web and standards for font and color usage. In addition, they provided training, both in person at several locations and via Lotus Sametime for remote users unable to travel to one of the training locations.
The development team and the company decided that, for the months following the implementation, meetings would be held to discuss the application with corporate and franchise users. They collected suggestions for changes and documented them for future releases. A maintenance agreement detailed application support (fixing any bugs) for a specific timeframe, and in-house personnel were trained and assigned to the help desk.
FlapJack Franchise may be fictional, but a collaborative Web site is a very real groupware application. As in all groupware applications, the time spent in the discovery process is invaluable, and a clear way to represent the needs discovered, in the form of a working design document, helps keep all interested parties involved and informed. While
Victory!
custom groupware applications can take 30 days to 300 days, having a clear, documented vision provides the strong backbone necessary to carry it to a successful completion.
FLAPJACK WEB SITE COMPONENTS
Overall Components
• Discovery process
• Design document
• Hardware, software
• Internet connection
• Project management
• Page layout
• Graphics
• Documentation
• Training
Main Web Site
• Main page design
• Page template to create general pages
• Page template to create product pages
• Contact form
• Current job postings for the corporate office
• World map with links to all franchise pages
Franchise Site Template
• Main page design
• Page template to create general pages
• Page template to create product pages
• Contact form
• Current job postings for the franchise location
Intranet
• Login screen, security
• Main page design
• Operations information
• Calendars
• Contact information for all employees and franchises
• Discussion group for employees
Figure 1: Web site components are a starting point for estimating time and resources.
 |
WORKFLOW PROCESS FOR A NEW PAGE
Figure 2: This diagram provides a basic understanding of the workflow process to create a new page.
Editable with no approval (select users)
Editable with marketing approval
Manager flags for one of three options
Manager flags for archiving or not archiving Editable with full approval process required
*A
Once complete, author saves
Content committee notified
No
Author notified; copy of notification sent to marketing
Approved?
*B
Author makes changes; may add comments
Yes
Author makes changes; may add comments Author makes changes; may add comments
No Yes
Approved?
Style committee notified
Style committee reviews; may add comments
Approved?
Author notified
Once complete, author saves
Author makes changes; may add comments
Author notified
Yes
Manager notified Approved?
Marketing reviews; may add comments
Marketing notified
Once complete, author saves Once complete, author saves
Yes
No
Author notified
No
 |
 |
User clicks “Update
This Page” button UPDATING EXISTING WEB PAGES
Figure 3: Defining the update process of existing pages helps set the rules for efficient change management.
User listed as an approved editor?
New version created Marketing notified Author notified that page has been approved
Yes
No
Yes
User edits; may add comments; saves as “draft” until complete
Yes
Editable with no approval?
Editable with marketing approval?
 |
No No
New version created User edits; may add comments; saves
Once complete, user saves
Approved?
Page published directly to the Web with no archiving
Yes
Marketing reviews page; may add comments
User edits; may add comments; saves as “draft” until complete
Page follows complete approval process as if it were a new page (see *A through
*B in Figure 2)
No
Author edits page; may add comments
Page published to the
Web, replacing previous version
 |
Accessible Through LAN with Notes Client
(Red dotted lines represent links, solid black lines represents movement and replication of Web pages.)
SITE STRUCTURE
Figure 4: Defining the structure of a site helps maintain its planned organization.
Accessible Through Web Browser
 |
Archive for main site Archive for franchise sites
Main site (includes “draft” pages)
Intranet site Intranet site
London franchise site (includes “draft” pages)
Japan franchise site (includes “draft” pages)
New Zealand franchise site (includes “draft” pages)
Main site (“public” pages only)
London franchise site (“public” pages only)
Japan franchise site (“public” pages only)
New Zealand franchise site (“public” pages only)
FIREWALL
 |
Developer creates Web site application Employee user group tests Web site
Test group from general public tests Web site
TESTING PROCESS
Figure 5: A well-defined testing workflow process helps make testing more efficient and productive.
Developer tests Web site
Passes test?
Passes test?
Developer edits code
No
Yes
No
Yes
No
Yes
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online