Enduser Software Engineering for Web Authoring Tools

1

• End-user Software Engineering for Web Authoring
  Tools
• Bhuvana Gopal
• Under the guidance of Prof. Sebastian Elbaum
• Progress Report
• Oct 1, 2003

2
Motivation

• Two recent NSF workshops have determined that
  end-user programming is in need of serious
  attention 1.
• The number of end-user programmers in the U.S.
  alone is expected to reach 55 million by 2005, as
  compared to only 2.75 million professional
  programmers 1.
• Evidence abounds of the pervasiveness of errors
  in the software that end users create 2.
• Despite its accessibility to wide audiences,
  end-user programming is still programming, and
  programming is subject to errors.
• Use of end-user-written programs and spreadsheets
  is widespread and their lack of reliability is
  pervasive, improved reliability will impact a
  potentially huge number of business and personal
  computer users.
• Significant economic impact can be expected.

3
Motivation and our approach

• The objective of this project is to improve the
  reliability of software produced by end-user
  programming languages in general, and by web
  authoring tools in particular.
• Our approach The system will notice the user's
  reactions to sample values he/she tests, and will
  then suggest general principles about the
  spreadsheet, encouraging the user to refine or
  modify the suggestions.
• This collaboration between the system and user
  will incrementally generate formal specifications
  as the application evolves.
• These specifications can in turn be fed back to
  enhance reliability -- by automatically
  suggesting appropriate test values, by helping
  locate faults, and by ensuring continuing
  consistency with the specifications.

4
Web authoring tools

• Amaya (W3C)
• WYSIWYG editor/browser for Unix, Windows. HTML,
  XHTML, CSS, MathML, some SVG. Source available.
• DreamWeaver (Macromedia)
• WYSIWYG/source editor for MacOS,Windows.
• FrontPage(Microsoft)
• WYSIWYG editor for Windows.
• HomeSite(Macromedia)
• Source editor for Windows.
• HotMetal(SoftQuad)
• WYSIWYG editor for Windows.
• Websphere Studio Homepage Builder(IBM)
• WYSIWYG/source editor for Windows and Linux.
  Studio version supports (XML, WML, etc.) and
  linking to Websphere database systems.
• Arachnophilia ( free HTML editor for Windows)
• HTML-Kit (free HTML,XML editor for Windows)
• We chose MS-FrontPage for our prototype
  development as it is widely used, and hope to
  study Amaya as well. (Amaya is open-source)
• Create pages in Normal (WYSIWYG) View, or write
  code in HTML View.
• Integrated Folder List and Navigation Pane to set
  up and change links, banners, and other
  navigation while editing pages.

5
Our prototype- what does it do?

• Fetches information from various websites and
  integrates them into one single html page.
• Source webpages can be static html pages, dynamic
  scripts (JSP, ASP, PHP, CGI etc)
• User (in our case, the end-user) can enter
  information pertaining to different webpages, and
  our prototype allows them to get the integrated
  output on one single html page.
• Our application is very specific and does not
  constitute a market we chose to develop a
  simple application for a volunteering program
  such as Meals on Wheels.
• We have chosen a combination of
• Nutritional/health needs based menus/recipes
• Driving directions / maps
• Weather information pertaining to driving

6
Our prototype-architecture and technologies used

• Client-Server Architecture
• HTML, JavaScript, Java Server Pages(JSP)
• HTML, JavaScript- Client Side. Can be produced
  easily with the WYSIWYG editor (MS-FrontPage,
  Amaya)
• HTML request can be GET or POST (The HTML
  specifications technically define the difference
  between "GET" and "POST" so that former means
  that form data is to be encoded (by a browser)
  into a URL while the latter means that the form
  data is to appear within a message body. But the
  specifications also give the usage recommendation
  that the "GET" method should be used when the
  form processing basically for just getting
  (retrieving) data whereas "POST" may involve
  anything, like storing or updating data, or
  ordering a product, or sending E-mail.)

7
Client- server architecture using HTML,
Javascript (Client side scripting) and JSP
(Server side scripting).
8
Our prototype-architecture and technologies used,
and working

• JSP- Server Side Script. Requires a WebServer
  that can run JSP scripts, (we used Blazix),and a
  Java Run-Time Environment (we used
  j2sdk1.4.1_02).
• Our prototype contains 2 JSP files the first
  one, a basic HTML file with some JavaScript and
  the second, a processing JSP.
• The first file contains the front end form
  elements to retrieve nutritional, driving
  direction and weather information .
• These are actually three different websites, but
  we handle all of this is one single form,which
  posts its information to the processing JSP.
• Simple logic is used to choose between any of
  the three categories, or any combination thereof.
• The processing JSP retrieves the form element
  variable values from the request object, and
  separately sends relevant variables and their
  values to three different websites, using GET or
  POST, as appropriate.
• It also receives the returned HTML, and displays
  it in different frames, to the end-user.

9
Sample screenshot
10
Proposed testing solutions

• Our aim is to test and verify that the content
  outputted on the screen is accurate. We are not
  testing for broken links, spell checking etc for
  which tools are already available.
• Alternate, reliable sources of information for
  validation of content
• Assertions (preconditions, postconditions and
  invariants)

11
Testing challenges

• Content accuracy verification
• where and how do we incorporate assertions?
• Impact analysis of code, especially with respect
  to the assertions.
• How to extend what we use to test the prototype,
  to be able to test Web Authoring tools
  functionality as a whole?
• User motivation to be able to get input from
  them for assertions.
• Testing for different browsers, for different
  platforms for example, HTML rendering engines
  are different for IE 4,4 and 6, each with its own
  bugs.
• Handling problems associated with the use of
  templates in these tools.

12
Future work

• XML format for data for ease of parsing
• Analyzing where and what assertions could be used
  and instrumenting the web authoring tool source
  code
• developing an interactive mechanism for
  user-system collaboration
• developing algorithms for the system's part of
  the collaboration
• conducting experiments to evaluate
  effectiveness.
• Suggestions welcome!

13
References

• 1)M.Burnett, C.Cook, O. Pendse et al. End-User
  Software Engineering with Assertions in the
  Spreadsheet Paradigm, International Conference on
  Software Engineering, Portland, Oregon, May 2003.
• 2) Panko, R. What we know about spreadsheet
  errors. J. End User Computing, Spring 1998, 15-21.

14
Questions?