08
Tue, Oct
2 New Articles

Groupware Victory in 10 Easy Steps

Collaboration & Messaging
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.




Author and marketing notified that page has been approved


Page published to the Web

Author creates new page; may add comments

Author enters content; saves as “draft” until complete


 Content committee reviews; may adds comments



Groupware_Victory_in_10_Easy_Steps06-00.png 852x860

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




Author creates new page; may add comments

Author enters content; saves as “draft” until complete



Groupware_Victory_in_10_Easy_Steps06-01.png 95x60




Page follows complete approval process as if it were a new page (see *A through

*B in Figure 2)

Author notified

If flagged for archiving, an agent archives previous version of page; if not flagged for archiving, previous version deleted



Groupware_Victory_in_10_Easy_Steps07-00.png 841x581

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?




Author notified

If flagged for archiving, an agent archives previous version of page; if not flagged for archiving, previous version deleted



Groupware_Victory_in_10_Easy_Steps07-02.png 95x60

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




Author notified

If flagged for archiving, an agent archives previous version of page; if not flagged for archiving, previous version deleted



Groupware_Victory_in_10_Easy_Steps07-01.png 95x60

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




New Zealand franchise site (includes “draft” pages)



Groupware_Victory_in_10_Easy_Steps08-00.png 635x691

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




Test group from general public tests Web site


Passes test?


Web site released to public; functionality and performance monitoring continues



Groupware_Victory_in_10_Easy_Steps09-00.png 391x827

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

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: