jump to navigation

Paper prototyping June 4, 2008

Posted by Coolguy in Web Applications.
Tags:
1 comment so far

What is it ?

Paper prototyping is low-fidelity method of usability testing that is useful for Web sites and Web applications. They are used clarify requirements and enable draft interaction designs to be very rapidly simulated and tested.

What are the benefits ?

  • With paper prototypes, potential usability problems can be detected at a very early stage in the design process before any code has been written.
  • Easy iterations. Because the prototype is all on paper, you can modify it very easily to fix the problems you find.
  • Eliminate technology variables from the usability testing equation
  • Cost. If you are on a shoestring budget, paper is a great low-cost alternative to many software packages

What do you measure ?

  • Efficiency — How long does it take people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.)
  • Accuracy — How many mistakes did people make? (And were they fatal or recoverable with the right information?)
  • Recall — How much does the person remember afterwards or after periods of non-use?
  • Emotional response — How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend?

How is it done ?

  • You first decide on the tasks that you’d like the user to accomplish.
  • Next, you make screen shots and/or hand-sketched drafts of the windows, menus, dialog boxes, pages, popup messages, etc. that are needed to perform those tasks.
  • Then you conduct a usability test by having one or two developers play the role of “computer,” manipulating the pieces of paper to simulate how the interface would behave.
  • Users are given realistic tasks to perform by interacting directly with the prototype — they “click” by touching the prototype buttons or links and “type” by writing their data in the prototype’s edit fields. (Using transparency or removable tape prevents the prototype from being written on directly.)
  • A facilitator (usually someone trained in usability) conducts the session while other members of the development team observe and take notes.
  • The “computer” does not explain how the interface is supposed to work, but merely simulates what the interface would do.
  • Debrief users afterward to measure interface recall

What do you don’t need for this exercise ?

  • Don’t spend time making the prototype look neat before you test it — if it’s legible, it’s good enough.
  • Straight lines or typed text. If the user can’t read something, it’s OK to tell them what it says. (But if the user doesn’t understand a term, don’t explain it — change it.)
  • Images or icons. Use words instead. For example, for the company logo, you can just draw a box around the words “company logo.” If images are part of the content (a product catalog, for example), you can paste them into your prototype using restickable glue, which allows you to rearrange the page later
  • Color.Color can’t save an inherently flawed design — do your initial testing with grayscale printouts of screen shots, or sketches using any dark-colored marker.
  • Consistent sizing of components. Unless you’ve got a small or densely-packed display, don’t worry about adhering exactly to a grid. It’s OK if components are of varying sizes.

What is it good for ?

  • Concepts and terminology. Do the target users understand the terms you’ve chosen? Are there key concepts they gloss over or misconstrue?
  • Navigation/workflow. If there’s a process or sequence of steps, does it match what users expect? Do they have to keep flipping back and forth between screens? Does the interface ask for inputs that users don’t have, or don’t want to enter?
  • Content. Does the interface provide the right information for users to make decisions? Does it have extra information that they don’t need, or that annoys them?
  • Page layout. Although your scribbled screens may not be pretty, you’ll still get a sense of whether users can find the information they need. Do you have the fields in the order that users expect? Is the amount of information overwhelming, not enough, or about right?
  • Functionality. You may discover missing functionality that users need, or functionality you’d planned but users don’t care about.

What is not good for ?

  • Technical feasibility. Paper prototypes don’t demonstrate technical capability. It’s possible to create a paper prototype that can’t actually be implemented. To avoid this, its recommend that there always be at least one person involved who understands the technical constraints.
  • Download time or other response time. Because a person simulates the behavior of the computer, the “response time” is artificial.
  • Scrolling. Subtle problems with Web page designs discourage the user from scrolling either down the page or back up to the top. These problems cant be found with a paper prototype.
  • Colors and fonts. If you really need to see how something looks on a computer screen, paper prototyping can’t show you that. It’s a good idea to involve the graphic designer in the paper prototype tests because he may find issues that influence the visual aspects of the final design.

Why not just use HTML to create a mockup ?

  • Three researchers at Verizon compared the type and number of problems found with a low-fidelity (i.e., paper) prototype as compared to a working prototype. They found that there was a significant degree of overlap between the problems found using the two different methods. Although the working prototypes did uncover a few more problems, they also took significantly longer to develop than the low-fidelity ones — weeks instead of days. These results indicate that there are diminishing returns from taking the additional time to develop a polished prototype.
  • Zero coding effort. While it’s possible to mock up a decent-looking interface pretty quickly in VB, Dreamweaver, etc., writing the code to make the interface respond properly to the user’s inputs can be time-consuming. With a paper prototype, the time spent coding is zero — even if you’re a real whiz, it’s hard to be faster than that!
  • Avoid nit-picky feedback. A polished-looking design can actually encourage the wrong kind of feedback. e:g Those fields don’t line up. Paper prototypes avoid that kind of feedback because it’s obvious to users that you haven’t specified the look yet. This encourages users to focus on the concepts and functionality.
  • Encourage creativity. Our brains respond more creatively to things that look somewhat unfinished. And users — especially non-technical ones — are often less intimidated by paper prototypes than by computers, so they’ll feel more comfortable exploring your design.

Tips for facilitators and observers

  • When participants arrive for a usability test, explain that you know the design has some rough edges.
  • Planning, preparing, and conducting a handful of usability tests typically take on the order of a week of hands-on time, spread out over 2-4 weeks
  • Stay for the Entire Test
  • Remain Silent While the Users Are Working
  • If users get stuck on a task, that means that there is a wealth of information youshould be fervently taking notes on
  • No Helping. During the test, it’s likely that users will have problems using the interface, and it is normal to feel a temptation to help. Please don’t. Instead, try to understand why it was that the user got stuck or went down the wrong path. It’s the facilitator’s role to get users back on track if they get really stuck.
  • Avoid “Design Questions”. You will have an opportunity to ask questions after each task. Questions that ask the user their opinions about how to design aspects of the application (such as, “Where would you like to see these navigation buttons?”) can take a lot of time to answer and produce only limited results. Instead, focus on trying to understand the problem—we’ll come up with solutions later, outside the test.
  • Here are more tips.

What are the steps?

  • Pick the target user to focus on for this series of tests. (6-12 users). If you decide to test existing customers, you may already have an in-house source of users. If not you can use market research firms.
  • Decide who will facilitate and observe the sessions.
  • Defining the tasks you will ask the users to attempt with the interface
  • Developing a paper prototype of the interface
  • Holding a “rehearsal” to prepare for the usability tests
  • Conducting the usability tests while members of the usability team observe and take notes
  • Responding to the issues we discover from the tests by making as many changes between tests as possible.

Here is a good book devoted to this subject, if you need more info.

Advertisements

Website on steroids September 26, 2007

Posted by Coolguy in IT Infrastructure, Web Applications.
Tags: , ,
2 comments

When a user types in a URL to request a Web page, the page is created by an application server, which executes a script that builds the page. This script contains actions such as calls to database systems to retrieve content. The result is an HTML “blueprint” for the requested page.

The page is then delivered back to the browser in a quick, text-only, nonbandwidth-intensive transfer that does not incorporate graphics. Finally, the browser must fetch the graphics, requesting each object from the appropriate server address based on the embedded URLs in the HTML page.

Because browsers are limited to downloading two to four objects at a time and a typical Web page may contain 30 to 40 embedded objects, a good deal of back-and-forth handshaking between the browser and server is required to complete the loading of a page

Solutions to speed up

Address both Network latency & Server latency.

Network Latency
Network Caching addresses network latency. By storing and serving objects from the network edge, caching slashes the time it takes a browser to load an object. Hardware applicances which help caching are NetCache from NetApp and Cache Server Director from Radware. Even for dynamic content, static elements like logos etc could be cached.

Edge delivery is another option.

Caching is now a sophisticated programmable tool. You cannot just enable caching after an application is written. You have to start thinking about using caching right from the architectural stage. Caching doesn’t effectively address dynamic page generation, which typically accounts for 40% of the time required to deliver a Web page

Dynamic content accelerators

A dynamic-content accelerator is positioned between the Web server and back-end resources to field and fill logic requests. Relying on the expectation that even personalized content will make use of some recycled data, content accelerators reduce the number of application server and database calls needed to compose an HTML page response.

One such product from Chutney and spider cache

ESI

Edge Side Includes (ESI), HTML-based language, which has been proposed to the World Wide Web Consortium as an industry standard, defines fragments of Web pages, allowing them to be assembled and updated at the edge of the Internet. With ESI, companies can set rules within Web pages, alerting the cache when it is necessary to retrieve fresh information from an origin server and when cached content can be used. Then new content from origin servers can be combined with cached content so that an entire Web page can be assembled at the network’s edge – no need to retrieve complete pages from origin infrastructure.

Cantos uses ESI and Akamai

Tangosol can be used to cache data from the database.

Links:
Original Article
Another Article
Creating a cache friendly website
Edge servers and how it works
MTV Case Study
Jcache
Spiritsoft

Web analytics softwares February 4, 2007

Posted by Coolguy in Web Applications.
Tags:
add a comment
http://www.opensymphony.com/clickstream/

http://www.omniture.com/web_analytics-product_overview.html

http://www.webtrends.com/

Test edit

powered by performancing firefox

Application Lifecycle Events August 16, 2005

Posted by Coolguy in Servlets/Jsp, Web Applications.
add a comment
  • The application events facility gives the Web Application Developer greater control over the lifecycle of the ServletContext and HttpSession and ServletRequest , allows for better code factorization, and increases efficiency in managing the resources that the Web application uses.
  • Application event listeners are classes that implement one or more of the servlet event listener interfaces.
  • They are instantiated and registered in the Web container at
    the time of the deployment of the Web application. They are provided by the Developer in the WAR.
  • Servlet event listeners support event notifications for state changes in the
    ServletContext , HttpSession and ServletRequest objects.
  • Servlet context listeners are used to manage resources or state held at a JVM level for the application.
  • HTTP session listeners are used to manage state or resources associated with a series of requests made into a Web application from the same
    client or user.
  • Servlet request listeners are used to manage state across the lifecycle of servlet requests.
  • Event Type Description Listener Interface
    Servlet Context Events
    Lifecycle

    The servlet context has just been created and is available to service its first request, or the servlet context is about to be shut down. javax.servlet.ServletContextListener
    Changes to attributes

    Attributes on the servlet context have beenadded, removed, or replaced. javax.servlet.ServletContextAttributeListener
    HTTP Session Events
    Lifecycle

    An HttpSession has been created, invalidated,or timed out. javax.servlet.http.HttpSessionListener
    Changes to attributes

    Attributes have been added, removed, or replaced on an HttpSession . javax.servlet.HttpSessionAttributeListener
    Session migration

    HttpSession has been activated or passivated. javax.servlet.HttpSessionActivationListener
    Object binding

    Object has been bound to or unbound from Httpsession javax.servlet.HttpSessionBindingListener

Servlet Request Events
Lifecycle

A servlet request has started being processed by Web components.

.

javax.servlet.ServletRequestListener
Changes to attributes

Attributes have been added, removed, orreplaced on an ServletRequest .. javax.servlet.ServletRequestAttributeListener

    An Example of Listener Use:

  1. When the application starts up, the listener class is notified. The application logs on to the database, and stores the connection in the servlet context.
  2. Servlets in the application access the connection as needed during activity in the Web application.
  3. When the Web server is shut down, or the application is removed from the Web server, the listener class is notified and the database connection is closed.

Listener Class Configuration

  • The Developer of the Web application provides listener classes implementing one or more of the listener classes in the javax.servlet API.
  • Each listener class must have a public constructor taking no arguments.
  • Listener classes are declared in the Web application deployment descriptor using the listener element. They are listed by class name in the order in which they are to be invoked.
  • The Web container creates an instance of each listener class and registers it for event notifications prior to the processing of the first request by the application.
  • During Web application execution, listeners are invoked in the order of their registration.
  • On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown.
  • The following example is the deployment grammar for registering two servlet context lifecycle listeners and an HttpSession listener.
    Suppose that com.acme.MyConnectionManager and com.acme.
    MyLoggingModule both implement javax.servlet.ServletContextListener , and that com.acme.MyLoggingModule additionally implements
    javax.servlet.HttpSessionListener. Also, the Developer wants
    com.acme.MyConnectionManager to be notified of servlet context lifecycle events before com.acme.MyLoggingModule. Here is the deployment descriptor for this application:
    <web-app>

    <display-name>MyListeningApplication</display-name>

    <listener>

    <listener-class>com.acme.MyConnectionManager</listener-

    class>

    </listener>

    <listener>

    <listener-class>com.acme.MyLoggingModule</listener-class>

    </listener>

    <servlet>

    <display-name>RegistrationServlet</display-name>

    …etc

    </servlet>

    </web-app>

  • The container is required to complete instantiation of the listener classes in a Web application prior to the start of execution of the first request into the application.
  • The container must maintain a reference to each listener instance until the last request is serviced for the Web application.
  • Application code inside a listener may throw an exception during operation.
  • The container must allow unhandled exceptions to be handled by the error page mechanism
  • In distributed Web containers, HttpSession instances are scoped to the particular JVM servicing session requests, and the ServletContext object is scoped to the Web container’s JVM.
  • Listener classes provide the Developer with a way of tracking sessions within a Web application. It is often useful in tracking sessions to know whether a session became invalid because the container timed out the session, or because a Web component within the application called the invalidate method.

Web Applications in Java August 16, 2005

Posted by Coolguy in Servlets/Jsp, Web Applications.
add a comment
  • A Web application is a collection of servlets, HTML pages, classes, and other resources that make up a complete application on a Web server.
  • By default, an instance of a Web application must run on one VM at any one time. This behavior can be overridden if the application is marked as
    “distributable” via its deployment descriptor. An application marked as
    distributable must obey a more restrictive set of rules than is required of a normal Web application.
  • The servlet container must enforce a one to one correspondence between a Web application and a ServletContext.A ServletContext object provides a servlet with its view of the application.
  • A Web application may consist of the following items:
    • Servlets
    • JSP Pages
    • Utility Classes
    • Static documents (HTML, images, sounds, etc.)
    • Client side Java applets, beans, and classes
    • Descriptive meta information that ties all of the above elements together
  • A Web application exists as a structured hierarchy of directories.
  • The root of this hierarchy serves as the document root for files that are part of the application.
  • For example, for a Web application with the context path /catalog in a Web container, the index.html file at the base of the Web application hierarchy can be served to satisfy a request from /catalog/index.html
  • Web containers must reject Web applications defining a context path could cause potential conflicts in this URL namespace. This may occur,
    for example, by attempting to deploy a second Web application with the same context path.
  • Requests are matched to resources in a case-sensitive manner
  • A special directory exists within the application hierarchy named “WEB-INF “. This directory contains all things related to the application that aren’t in the document root of the application.
  • The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may
    be served directly to a client by the container.Any requests from the client to access the resources in WEB-INF/directory must be returned with a SC_NOT_FOUND (404) response.
  • The contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext
  • If the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed directly to the Web client, he may place it under this directory.
  • The contents of the WEB-INF directory are:
    • The /WEB-INF/web.xml deployment descriptor.
    • The /WEB-INF/classes/directory for servlet and utility classes. The classes in this directory must be available to the application class loader.
    • The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files.
  • The Web application class loader must load classes from the WEB-INF/classes directory first, and then from library JARs in the WEB-INF/lib directory.
  • The following is a listing of all the files in a sample Web application:
    /index.html
    /howto.jsp
    /feedback.jsp
    /images/banner.gif
    /images/jumping.gif
    /WEB-INF/web.xml
    /WEB-INF/lib/jspbean.jar
    /WEB-INF/classes/com/mycorp/servlets/MyServlet.class
    /WEB-INF/classes/com/mycorp/util/MyUtils.class
  • Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools.
  • The Web application deployment descriptor includes the following types of configuration and deployment information:
    • ServletContext Init Parameters
    • Session Configuration
    • Servlet/JSP Definitions
    • Servlet/JSP Mappings
    • MIME Type Mappings
    • Welcome File list
    • Error Pages
    • Security
  • When a number of applications make use of the same code or resources, they will typically be installed as library files in the container. These files are often common or standard APIs that can be used without sacrificing portability.
  • Files used only by one or a few applications will be made available for access as part of the Web application. The container must provide a directory for these libraries.
  • E:g In tomcat, for classes and resources that must be shared across all web applications, place unpacked classes and resources under $CATALINA_BASE/shared/classes, or place JAR files containing those classes and resources under $CATALINA_BASE/shared/lib. $CATALINA_HOME/common/classes contains additional classes that are made visible to both Tomcat internal classes and to all web applications
  • The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR.
  • The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource
  • A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application.
  • To allow developers to customize the appearance of content returned to a Web client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions.
  • The syntax allows the configuration of resources to be returned
    by the container either when a servlet or filter calls sendError on the response for specific status codes, or if the servlet generates an exception or error that propagates to the container.
  • If the sendError method is called on the response, the container consults the list of error page declarations for the Web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
  • A servlet or filter may throw the following exceptions during processing of a request:
    • runtime exceptions or errors
    • ServletExceptions or subclasses thereof
    • IOExceptions or subclasses thereof
  • The Web application may have declared error pages using the exception-
    type element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type element.
  • Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type.Same goes with error-page declarations using the status-code element.
  • If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500.
  • Web Application developers can define an ordered list of partial URIs called welcome files in the Web application deployment descriptor.
  • If a Web container receives a valid partial request, the Web container must examine the welcome file list defined in the deployment descriptor.
  • If no matching welcome file is found in the manner described, the container may handle the request in a manner it finds suitable. For some configurations this may mean returning a directory listing or for others returning a 404 response.
  • Provision has been made in the Web application deployment descriptor for specifying information allowing a servlet to obtain references to resources and enterprise beans. The deployment elements that contain this information are:
    • env-entry
    • ejb-ref
    • ejb-local-ref
    • resource-ref
    • resource-env-ref
  • The developer uses these elements to describe certain objects that the Web application requires to be registered in the JNDI namespace in the Web container at runtime.
  • Servlet containers that are part of a J2EE technology-compliant implementation are required to support this syntax.
  • When a web application is deployed into a container, the following steps must be performed, in this order, before the web application begins processing client requests.
    • Instantiate an instance of each event listener identified by a
    <listener>
    element in the deployment descriptor.
    • For instantiated listener instances that implement ServletContextListener , call the contextInitialized() method.
    • Instantiate an instance of each filter identified by a
    <filter>
    element in the deployment descriptor and call each filter instance’s init()method.
    • Instantiate an instance of each servlet identified by a
    <servlet>element that includes a
    <load-on-startup>
    element in the order defined by the load-on-startup element values, and call each servlet instance’s init()method.

Lucene August 9, 2005

Posted by Coolguy in Web Applications.
Tags:
add a comment

java.net: Did You Mean: Lucene?

Harvest: A Distributed Search System May 30, 2005

Posted by Coolguy in Web Applications.
Tags:
add a comment

Harvest: A Distributed Search System

HTTPUnit: black box web testing May 6, 2005

Posted by Coolguy in Web Applications.
Tags:
add a comment

HTTPUnit: black box web testing

ONJava.com: Black Box Web Testing with HttpUnit May 6, 2005

Posted by Coolguy in Web Applications.
Tags:
add a comment

ONJava.com: Black Box Web Testing with HttpUnit

OpenSymphony – Welcome To OpenSymphony March 29, 2005

Posted by Coolguy in Web Applications.
Tags:
add a comment

web analytics
OpenSymphony – Welcome To OpenSymphony

plumtree analytics server

used to track website user activity