development of a context based aid for web navigation
TRANSCRIPT
Development of a context based aid for web navigation
Richard Caird
BSc (Hons) Computer Science
University of Bath
May 2004
This dissertation may be made available for consultation within theUniversity Library and may be photocopied or lent to other librariesfor the purposes of consultation.
Signed: . . . . . . . . . . . . . . . . . . . . .
ii
Abstract
Internet users often suffer from the poor navigational qualities of many badly designed websites. These problems are often compounded by the lack of functionality that Internet browsers provide when trying to traverse large complicated sites, and often cause a loss of context for the user. Many users are forced to maintain several trains of thought at once and as such have to run many separate browser windows simultaneously.This dissertation will attempt to discover ways in which a web users journey may be aided by the provision of a tool that graphically displays sites of interest, and the users’ path through them.
iii
Acknowledgements
I would like to thank my project supervisor Claire Willis, my housemates James, Ed, Gaz and Sylvie, as well as all the people who offered their time to take part in user testing.
iv
Development of a context based aid for web navigation
submitted by Richard Caird
COPYRIGHTAttention is drawn to the fact that the copyright of this dissertation restswith its author. The Intellectual Property Rights of the products producedas part of the project belong to the University of Bath (seehttp://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone whoconsults it is understood to recognise that its copyright rests with its authorand that no quotation from the dissertation and no information derived fromit may be published without the prior written consent of the author.
DeclarationThis dissertation is submitted to the University of Bath in accordance withthe requirements of the degree of Bachelor of Science in the Department ofComputer Science. No portion of this work in this dissertation has beensubmitted in support of an application for any other degree or qualificationof this or any other university or institution of learning. Except wherespecifically acknowledged, it is the work of the author.
Signed:……………………………….
v
Contents1. Introduction ................................................................................................... 12. Literature Review .......................................................................................... 2
2.1 Introduction.............................................................................................. 22.2 Navigation................................................................................................ 22.3 Colours, Fonts and Layout........................................................................ 32.4 Screen Real Estate.................................................................................... 52.5 Tree Generation........................................................................................ 52.6 Available Software ................................................................................... 62.7 Conclusion ............................................................................................... 6
3. Requirements................................................................................................. 83.1 Requirements Analysis ............................................................................. 8
3.1.1 System Perspective ............................................................................ 83.1.2 User characteristics ............................................................................ 83.1.3 Operating Environment ...................................................................... 93.1.4 Programming Language ..................................................................... 93.1.5 User documentation ........................................................................... 93.1.6 System Features ............................................................................... 10
3.2 Requirements Specification .................................................................... 123.2.1 System Perspective .......................................................................... 123.2.2 User characteristics .......................................................................... 123.2.3 Operating Environment .................................................................... 123.2.4 Programming Language ................................................................... 123.2.5 User documentation ......................................................................... 123.2.6 System Features ............................................................................... 12
4. Design ......................................................................................................... 164.1 Design Overview.................................................................................... 164.2 Class Design........................................................................................... 16
4.2.1 Tree Structure .................................................................................. 164.2.2 Saving and Loading ......................................................................... 16
4.3 Interface Design ..................................................................................... 174.3.1 Containers........................................................................................ 174.3.2 Link objects ..................................................................................... 184.3.3 Tree drawing algorithm.................................................................... 194.3.4 Displaying additional information .................................................... 194.3.5 Saving and Loading ......................................................................... 194.3.6 Menus .............................................................................................. 20
5. Implementation............................................................................................ 215.1 Class Structure ....................................................................................... 215.2 Tree structure ......................................................................................... 215.3 User Interface ......................................................................................... 22
5.3.1 Overall Design ................................................................................. 225.3.2 PicFrame Container ......................................................................... 225.3.3 PicDetails Container ........................................................................ 235.3.4 Scrollbars......................................................................................... 235.3.5 Context Menus................................................................................. 24
vi
5.4 Thumbnail Processing ............................................................................ 255.5 Microsoft Internet Explorer .................................................................... 25
5.5.1 Overview ......................................................................................... 255.5.2 C++ Classes ..................................................................................... 255.5.3 The Windows Registry..................................................................... 255.5.4 The Band Object .............................................................................. 265.5.5 The Internet Explorer Object ............................................................ 265.5.6 Document Object Model .................................................................. 275.5.7 Context Menus................................................................................. 27
6. System Testing ............................................................................................ 296.1 System Testing ....................................................................................... 29
6.1.1 Overview ......................................................................................... 296.1.2 Errors Raised ................................................................................... 29
6.2 User Testing ........................................................................................... 306.2.1 Users................................................................................................ 306.2.2 Testing Strategy ............................................................................... 30
7.1 Further work........................................................................................... 317.2 Final Remarks ........................................................................................ 31
8. Bibliography ................................................................................................ 33Appendix A ..................................................................................................... 35Appendix B ..................................................................................................... 37Appendix C ..................................................................................................... 40Appendix C ..................................................................................................... 41Appendix D ..................................................................................................... 46Appendix E...................................................................................................... 52
1
1. Introduction
Internet users often suffer from the poor navigational qualities of many poorly designed websites. These problems are compounded by the lack of functionality Internet browsers provide when trying to traverse these large complicated sites, and often cause users to miss information when following links from one page to another. Current context based navigation systems fall into two categories, the first with a global context and the second with a local context. Those with a global context attempt to provide a structure for entire web systems, but as these grow exponentially they are all but impossible to display. [Park. J. Kim. J (2000)].
This project will aim to reduce users problems in traversing large websites with many links, by providing a map to show the users path through “hyperspace”. In doing this the system will aim to reduce the amount of additional effort the user must expend on maintaining several trains of thought.
Objectives
To provide a graphical view of a users journey. To provide the ability for users to manipulate this view of their journey as they
see fit. To provide additional information about each web site such as the date and time
visited. To allow the user to store their journey and return to it at a later time.
Chapter 2 discusses relevant literature to issues raised by these objectives, such as the user of screen space, and various HCI techniques. The processes of requirements capture and specification are listed in Chapter 3, and Chapter 4 shows the design of the system. Chapter 5 shows details of the implementation and where key decisions were made. Finally chapter 6 gives details of both the user and system testing plans. Chapter 7 discusses shortcomings of the system with respect to the requirements as well as areas for further improvement.
2
2. Literature Review
2.1 Introduction
There are several important concepts that need to be clarified and further researched before this project can progress. These include answering several key questions, both about current web browsing trends and user interface design.Firstly the question of how users navigate their way through such vast amounts of non-linear data without suffering from the “lost in hyperspace” phenomenon [Conklin. J. (1987)] Issues such as the validity of back and forward buttons and what part they play in allowing a user to get lost should be also clarified.Research into Human Computer Interaction (HCI) is required to decide the best ways to present this data; including whether to display entire websites or just where the user has been.Furthermore the issue of screen “real estate” must be addressed, an area not given enough thought in many HCI systems. Finally, as a key objective; reviews and evaluation of already available software must be undertaken, including a discussion of their shortcomings.
2.2 Navigation
Internet navigation is a subject that has been discussed at length in many papers and in many different contexts. The majority of research suggests that there are two main forms of Internet browsing, directed and undirected. Although Catledge. L.D. and Pitkow. J.E (1995) go on to state a third form: general purpose browsing; consulting sources that have a high likelihood of items of interest. The validity of this is now somewhat questionable, fifteen years after it was written. Directed browsing is where a user has a specific topic in mind, and goes on a search for material relating to it. In an undirected search or “surf”, a user follows links in a relatively random pattern, looking at information that may interest them. Current web browsers are ideal for the latter, however have very little support for directed searches. Conklin. J. (1987) breaks the problem faced with current browsers into two parts:
Disorientation: the tendency to lose ones’ sense of location and direction in a non-linear document; and
Cognitive overhead: the additional effort and concentration necessary to maintain several tasks or trails at one time.
We can therefore justify our final goal as; creating a system that reduces both disorientation and cognitive overhead and is therefore an aid to perform directed searches.
Deeper discussion of current directed searches reveal the “hub and spoke” terminology explained by Catledge. L.D. and Pitkow .J.E (1995). The term hub and spoke refers to the frequent use of backtracking within a specific website. Users start at a certain “hub” page and then explore onwards from this page, creating spokes as they go. Whenever they run out of relevant information on a given “spoke” they click the back button to return to the “hub” page. New “hubs” are created from former spokes as they explore new ideas and content that then go on to generate new spokes. According to a study by Catledge. L.D. and Pitkow .J.E (1995) at the Georgia Institute of Technology College; over 40% of Internet actions involved the back button, which goes some way to supporting their hub and spoke theory.
3
As mentioned, current browsers do little to help with directed searches. The provided history and bookmark functions are unhelpful in a variety of ways. Bookmarks are cumbersome, too permanent in this context and a further overhead to maintain. [Newfield. D. Sethi. B.S. Ryall. K (1998)]. They also provide no way of storing how you got to that position and hence cause a loss in context. The history feature is an equally unhelpful attempt at storing a set of non-linear movements in a series of what are effectively “temporary bookmarks”. Browser histories are seldom used as a tool for helping navigation and do not store every page that has been visited. Furthermore, they do not store sites in the order they have been viewed, simply because sites can be viewed concurrently, and the history mechanism has no support for displaying this [Newfield. D. Sethi. B.S. Ryall. K (1998)].
The only way to effectively display a non-linear path to a user; in any context, is to draw a map showing each place they have visited, and how they moved from one position to another. It is in drawing maps of this type that we can understand Catledge and Pitkow’s (1995) hub and spoke terminology, and furthermore, by dynamically drawing maps of this nature we should be able to decrease a users’ disorientation. By slightly modifying this concept further and allowing users to add links they may wish to view later onto their map we can reduce the cognitive overhead of maintaining several trails of information concurrently.
2.3 Colours, Fonts and Layout
When designing any user interface it is important to take into account the user’s physical capabilities. The term cognition is used to describe the interpretation of information from the outside world that is received through the senses. [Faulkner. F. (1998)] Cognition can be redefined as information gathered through the five senses of vision, hearing, taste, smell and touch. The aim of this section is to explore important concepts concerning human cognition of a computer system and more specifically the vision aspect of interaction.
The human eye is incredibly sensitive to colour variations and a trained colourist can distinguish among 1,000,000 colours [Tufte. E (1990)].Obviously users of the system being developed will not be trained colourists, and it is in fact safe to say that the use of 20 to 30 colours will actually reduce the value of any colour information altogether, and cause the user more difficulties in finding what they want [Oborne. D. J (1985)].
The use of colour is therefore very important in interface design, but avoiding overuse of colour is equally important. The use of compatible colours is also crucial; applying a blue on another shade of blue will require a significant amount of cognitive overhead and mean more effort will go into reading the information than actually taking it in. Hard and fast rules where human beings are concerned are always dangerous [Faulkner. F. (1998)]and therefore the choice of colours should be relative to the task at hand. It is quoted “…the general guideline for computer generated images is no more than five to seven colors at a time…” [Retrofit of flat panel color displays in the F16A/B. In Proceedings IEEE/AIAA 11th Digital Avionics Systems Conference (Seattle, Washington, 1992), pp.323-328]. Although there is no explanation as to from where this number has been obtained, it is safe to assume that a number larger than this is likely to cause confusion, concluded both from personal experience and the stated texts.
4
The human eye is less sensitive to colour at the periphery, accurate colour discrimination is only possible to ±60 degrees and the limit of colour awareness is approximately ±90 degrees of the straight ahead position. At the periphery the eye is least sensitive to red, green and yellow, but most sensitive to blue light. It is for this reason that blue makes an excellent background colour, especially when used on a large screen. Towards the front of the eye colour vision is at its best, and the eye is more sensitive to yellow and red light. Small blue objects tend to get lost when placed directly in front, especially when a pale blue is used. Furthermore the eye needs to refocus between spectrally extreme colours, which is inevitably tiring. For this reason colours such as red, orange and yellow can all be viewed together comfortably, but the combination of reds and blues cannot. [Faulkner. F. (1998)]
Imhof’s first rule states that the use of colour is important and that “color spots against a light grey or muted field highlight and italicise data, and also help to weave overall harmony”. He goes on to say in his second rule “that the placing of bright colours mixed with white next to each other produces unpleasant results”. Although these rules were originally designed for static maps and graphs, it is reasonable to draw parallels between them and interface design and therefore adhere to them to some extent. This therefore implies that a given user interface should not overuse bright colours including white, and should not place them in close proximity to each other. Colours are often described as having temperature - as warm (purples, reds, oranges, and yellows), neutral (violets and greens), or cool (blue-greens and blues). Warm colours are often associated with fire and sun. Optically, warm colours generally appear to advance, coming toward the viewer. In a HCI sense this means that the use of warm colours is intuitive in order to indicate activity.
The choice of font and layout of information is also very important and various texts have conflicting views on this. The former being the argument between the use of serif versus san serif fonts. It is argued that the additional information provided by serif fonts gives extra clues as to what that letter is. More recently it is argued that because readers are now more accustomed to sans serif fonts they find them just as easy to read, in fact sometimes easier [Faulkner. F. (1998)]]. What is certainly true is that a mixture of many fonts, both serif and sans serif is not a good idea, and leads to a cluttered screen, which is more difficult for the brain to absorb.
Equally important to the colouring of information is its layout and the amount to display at a given time. For the purposes of HCI, the human brain consists of three types of memory:
Long-term memory Working memory Sensory memory
As the names suggest, long-term memory is where memories are stored, working memory is where conscious thought processes operates and sensory memory is the area of memory that deals with sensory input [Faulkner. F. (1998)]].It is important to bear in mind that although all three are used in human computer interaction, by limiting the amount the user has to store in long term memory the more easily they will be able to use the system. In the context of this project, this means keeping the interface simple and intuitive and displaying as little data as possible to keep the user within context. An example of a system that requires heavy use of long term memory are command line systems such as UNIX.
5
2.4 Screen Real Estate
It is important to note the problems of limited screen space, as unlike advances elsewhere, screen areas have not significantly increased in either size or resolution (dpi). Real estate in terms of pixels is precious and we have to choose carefully what to present and how to represent it. [Inder. R. Kilgour. J, Lee. J, (1998)].As a result we must find ways of displaying information concisely, but without losing important details. With relevance to this project; a way must be found to both compress large quantities of data, but allow the user to retain context of where they are in hyperspace.Important factors that require careful balancing in any interface design are: navigational, whitespace, system controls and actual content. These factors are especially relevant in a web-browsing context where in many sites large amounts of screen real estate are wasted on adverts, site logos, navigation and browser controls, leaving only a small percentage of the screen for actual content. Nielsen. J (1999) states that as a rule content should account for approximately 80% of screen usage, leaving just 20% for navigation, adverts, logosand browser controls. Any navigational aid developed will not only have little to no control over the content displayed, but will fall into two categories; both navigational and browser control.Also important is the value of certain areas of the screen in terms of user awareness. As we read from left to right, top to bottom, the top left area of the screen becomes the most valuable, and the bottom right the least. [Nielsen. J (1999)]
Over the years many ways of overcoming the issues of limited screen space have been devised. Xerox Star was the first to present an alternative to command line access, and developed the prevalent WIMP (Windows, Icons, Menus, and Pointers) paradigm that we see on a daily basis in effectively all commercial operating systems and software. A complimenting interface to WIMP is the fisheye view [G. Furness (1986)], which not only helps address the issue of limited screen space, but also reduces “Window Thrashing” [Henderson D. A. Card. S. K Rooms (1986)]. Fisheye views effectively alter the size of a given window, depending on whether or not it is in focus. This results in all windows being visible at a given time, however ones not currently in focus are reduced in size, and therefore less detail is shown. This approach may prove beneficial in the design of the interface to any system developed.
2.5 Tree Generation
The primary issue in drawing trees is establishing whether the tree to be drawn is free or rooted. The Internet can be thought of as a free tree. There is no root web page on the Internet from which all others can be found, and every page can both contain links to multiple child pages and multiple parent pages. A tree of this size and nature cannot be drawn in a way in which a user can make sense of. However, a rooted tree can model a users navigation of the Internet as the user will start from a given location (often their homepage) and will then proceed in a given manner to discover new web pages and new content. Obviously this model is not perfect, if a user returns to a page they have viewed before but from a different parent page a rooted tree structure will fail. There are two ways around this particular problem: Wittenburg and Sigman (1997) describe a method of analysing a website directly, and first generating a graph of hypertext links in the site and then flattening that into a tree structure with repeating nodes. This repeating node structure would allow the user to understand their navigational path with greater ease, and as long as the user is aware
6
when a repeated link has been added, should not significantly increase cognitive overhead. A second method would be to alter the focus of the tree to the original reference, thus eliminating the need for repeating nodes, but potentially providing a loss in context for the user.
Although neither of these solutions are optimal, the clear layout a rooted tree can provide overcomes many of its shortcomings and would provide a more concise and easier to understand view. Furthermore, algorithms to display rooted trees are both faster and easier to develop than those of their free counterparts.
2.6 Available Software
There are very few browsers available designed to help a user with directed searching. In fact the only implemented browser freely available was Nestor. Some key problems with this form of software are apparent in Nestor. Its construction of a tree like structure is very messy and takes up large areas of the screen, causing the user to constantly have to resize windows. However it does allow the user to modify the map as it is drawn which helps address this problem. Furthermore it allows the user to annotate the map as it is drawn, and save it and the end of a session, meaning a user can return to the session, without having to track down where they have been. [Zeilger. R.] From a HCI point of view a key problem with Nestor is the size of fonts, and its reliability at displaying page titles. While using on several occasions, Nestor failed completely to display the page names, and so most of the links displayed on the graph were without titles. On top of this, even when page names were displayed the size and colouring of them was inadequate. Especially given the amount of space already wasted by the map layout.
Another alternative to this is the TrailBlazer software available for systems running Mac OS X 10.3 (or later). This software while implementing a rooted tree format as previously discussed maintains a users context by maintaining screenshots of each web page visited. This gives the added advantage of bringing visual clues to the system so the user is able to return to a web page based only on what it looked like. However this system does not accomplish the main issues we wish to address. This is primarily because TrailBlazer has been designed as a replacement to the history function, and as such, doesn’t allow the user to view their progress in real time, but allows them to view previous browses at a later time. [MacWarriors, TrailBlazer, (2004) ]
2.7 Conclusion
It is important to bear in mind the use of colour: reds, oranges and yellows to indicate levels of activity, and more neutral colours to indicate static text. Furthermore it should be remembered that the use of colours at the periphery of vision is unhelpful, and that colours should not heavily contrast to avoid a cluttering effect. It is important to note that the combination of reds and blues is also unappealing, as it requires the eye to constantly refocus, however blues are mentioned as an ideal colour for a background.Many of these ideas conflict. Is it a good idea to use a blue background with warm foreground colours to indicate activity or not? Should a plainer background be used; again using warmth to emphasise activity.
As already mentioned there are no hard and fast rules that can be applied to any human computer interaction, so there is a certain level of flexibility in which methodology to follow. What can be stated with some certainty is the importance of not overwhelming the user with to much information, the importance of keeping the layout clean and keeping to
7
a standard font. Furthermore any interface must have a concise layout, given the amount of screen space available, and should be placed appropriately. We can conclude that for an interface such as this, placement should be towards the bottom of the screen as the website on display is of greater importance than any navigational aid. Furthermore we can state that given the environment the system will operate in, it should ideally imitate the interface used by standard web browsers.
The current range of available browsers do little to help a user conduct a directed search on the Internet. These browsers have no support for displaying a users path through the Internet and therefore allow users to become lost or disorientated very easily. The amount of information a user has to remember in order to navigate efficiently is an additional overhead, and takes time and energy away from the original task of searching. The only browser available which is an aid to directed searching is Nestor. Unfortunately not only does this not show where users can go, it also uses large amounts of screen space, and the user is constantly left window thrashing. It can therefore be concluded that there is a need for software that is able to fulfil this purpose, and that the construction of a prototype application will be the main aim of this project.
8
3. Requirements
The requirements specification below is based on the structure provided by the IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specification.
3.1 Requirements AnalysisThere are many different forms that a requirements analysis can take. The two major categories into which different types of analysis fall are bottom up and top down design. In top down design, the designer specifies each component of the system, and then continually breaks it down until at a suitable level to begin the coding process. In bottom up design individual parts of the system are specified in detail and may be coded. These components are then linked to create larger components and so forth. This form of analysis is well suited to systems where an exact set of system specifications is not available, and is ideal for designing a system based on possible scenarios.
Definitions
System – The software component of this dissertationBrowser – a piece of software that allows you to explorer the World Wide Web.Links – Hypertext links that redirect the browser to a different location.Map – An area of the screen in which links to web pages are displayed in a non-linear format.Tree – Refers to the structure of the mapParent – Refers to the link which currently stores a pointer to given linkChild – Refers to any link to which given link has a pointer forHTML – Hypertext Mark-up Language - language in which World Wide Web documents are written. URL - Uniform Resource Locator - A pointer to a page on the World Wide Web.
3.1.1 System PerspectiveThe aim of this project as concluded by the literature review is to produce a navigational aid for Internet browsing. This project should result in a prototype system that not only achieves these goals, but does so in a limited amount of screen space.
A possibility to consider in order to achieve these aims could be to providing a map based on either a rooted or free tree structure that is able to model either the users path so far, and/or the structure of websites. In using a free tree structure, the users navigation between any pages can be mapped and displayed to the user, making it an ideal candidate. However, algorithms to draw free tree structures are slow and can become easily cluttered. The use of a rooted tree, while not being able to show movement between pages already mapped, can be drawn more cleanly and in a smaller area.
Another option would be an area of the screen devoted to displaying additional information about a given web page. This information could include details such as the number of links the page has, and/or the number the user has visited. Further information could include limited information about where the user has come from.
3.1.2 User characteristicsThe users of the system may well be a very varied group and may well encompass anything from complete beginner computer and Internet users, through to regular users
9
and experts. Having noted this, more advanced Internet users are far more likely to have experienced the issues of disorientation and cognitive overload.
3.1.3 Operating EnvironmentThere are many different potential operating environments the system may have to work in. These range from the various Mac O/Ss’ through to Windows and Linux based operating systems. Ideally the system will operate in many or all of these operating systems, however, the nature of the system being a prototype implies that this is not a requirement.
3.1.4 Programming LanguageIn order for the prototype system to be of any use to a user, it must have a way of formatting and displaying html documents. To accomplish this, a web browser of some form must be integrated with the system. The system must therefore either implement a web browser of its own, or extend the functionality of an existing browser.
The implementation of an entire browser is beyond the scope of this project, and therefore the system must somehow extend the functionality of an existing one. The choice of browser implementation will be a determining factor in the programming language used and this therefore warrant further discussion. Possible browser implementations could be to:
Create an applet to run within any given web browser Extend an existing open source browser such as Mozilla Create a plug in application, for an existing browser.
Each of these systems has clear advantages and drawbacks. The creation of a java applet would allow the system to be cross compatible between any devices with a java enabled web browser. However this would lack the functionality of an extension to an existing browsers due to the security implications raised by java applets, and would also mean the system must be run in an html frame. Extending an existing browser would avoid these concerns, however could mean the resulting system is unusable on certain operating systems and would force the user into using that browser. The creation of a plug in applet would share these problems, however would allow the system to be embedded into a popular browser such as Microsoft Internet Explorer.
As already mentioned, any applet would be constructed in Java, whereas an extension to an existing open source browser would be forced to use the language of its implementation. A plug in application would be more flexible in terms of language used, as it could be implemented in C++ or Visual Basic. Furthermore the ease in which user interfaces can be created in Visual Basic make it ideal for rapid prototyping, a key ability in a project of this nature.
3.1.5 User documentationThe level of user documentation required, will be heavily dependant on the way in which the system is implemented. If the system is accessed and controlled via a simple GUI (Graphical User Interface), then user documentation will be minimal. However if the decision is taken to implement the system without a GUI (see section 3.1.6), then user documentation must be comprehensive (see section 3.2.5).
10
3.1.6 System Features
External Interface Requirements
User interface
The single most important feature of the system will be the user interface. As detailed in the literature review, there are many different possibilities in implementing user interfaces. A potential interface would be the now prevalent WIMP (Windows, Icons, Menus and Pointers) style of interaction. If this form of interface were to be implemented it would be convenient to create it in a similar style to that of standard WIMP web browsers where links may be clicked with the mouse, to change the page on display. Much like in standard WIMP browsers, the user would require the ability to move around the map independently, allowing them to navigate to where they wish.
A second possible interface could be a fish eye browser. In a fish eye browser the area in focus is enlarged, at the expense of areas which are not currently being viewed. A key advantage of fish eye browsers is that they help to prevent “Window Thrashing” [Henderson D. A. Card. S. K Rooms (1986)], as mentioned in the section 2.5. In this form of interface, the ability of the user to alter the area of focus would be essential, so they are able to see what they are doing clearly.
Section 2.6 discusses the TrailBlazer software, and its ability to give the user visual clues relating to sites they have visited previously, by providing a compressed image version of the web page. This tool incorporated into the interface instead of, or as well as providing a text reference, could give the user additional clues as to their location and context. Other alternatives to this could be to show the user a combination of the URL, page title or date and time they last visited the site.
Functional Requirements
Map Operations
As discussed in section 2.2, the bookmark and history functions provided by currently available browsers are unhelpful in reducing a users disorientation, as maintaining them becomes a job in itself. In order to combat this, the system must have the ability to store the users path in the form of a map, thus allowing the user to follow a trail as they wish, store it, and return to it at a later date. This feature will not only surpass the history features functionality but will also reduce the need for endless book marking of sites.
To compliment this ability and prevent oversized maps from wasting precious screen space, the user should also be able to start a new map at any given time and/or delete sections of the map they are not using.
If the system is implemented in this manner then a further requirement will be to refocus the user on the link representing the current website every time a new page is loaded. As mentioned in section 2.3 the human eye is less sensitive at the periphery, so it makes sense to position the active link as central as is possible. Furthermore if, as suggested in section 2.5, the map is implemented as a rooted tree structure then it may not be possible to display the movement from an existing link to another existing link. In order to prevent this from confusing the user, the map should not simply jump from existing link to existing link, and should instead provide some form of animation to show the movement.
11
In doing so, the user will be able to see where they came from and where they are going, with relative ease, and return there if they wish.
Browser Operations
Section 2.2 mentioned different strategies for web browsing and noted that current browsers “have very little support for directed searches”. In light of this, the ability for the user to add any given link from a web page onto the map would be helpful. This type of functionality would be especially helpful at search engines, which users tend to use as a form of “hub” from which they navigate back and forth from to load different pages of interest.
12
3.2 Requirements SpecificationThe requirements specification style this project was derived from a bottom up approach. As the final system is likely to be entirely event driven it was felt that an examination of possible user input in the form of use cases would not only help define the requirements, but that the resulting data would also aid the design of the system. As such the following requirements specification is based upon the use cases that can be found in Appendix A.
3.2.1 System PerspectiveThe decision was made to implement the system as a rooted tree structure, displaying each page as a hyperlink using their title. This form of implementation allows the user to clearly see both the path they have taken, and the possible places they may go. As such the use cases (see Appendix A) reflect this form of system.
3.2.2 User characteristicsSection 3.1.2 stated that the users of the system may vary in experience and knowledge. Despite this, the system will be aimed at experienced computer users, who use the Internet on a regular basis. This decision was taken, as users unfamiliar with web browsing are unlikely to experience the problems that the system is aiming to address, as detailed in the literature review.
The system should however be usable by inexperienced web users and should not hamper their use of the Internet. As such the system should have the ability to be disabled by any user with ease.
User testing on the system will therefore be undertaken by experienced Internet users, as it is this group to whom the system is designed to benefit.
3.2.3 Operating EnvironmentThe decision was taken to implement the system using Windows XP Home and Microsoft Internet Explorer 6. This decision was taken as the system need not be universally available and that Windows and Internet Explorer are not only the most readily available Operating System and Web browsing software available, but the most familiar to the majority of users.
3.2.4 Programming LanguageThe system will be implemented in Visual Basic as a plug in for Internet Explorer as this will allow the rapid creation of a user interface, and allow the user to use the system from the familiar setting of a popular web browser.
3.2.5 User documentationAs the system should implement a similar interface to that of the browser within which it resides, any documentation required will be minimal.
3.2.6 System Features
External Interface Requirements
User Interface
13
The decision was made to implement an interface similar to those used by standard WIMP web browsers. This type of interface; providing screen space is allocated efficiently, requires less user documentation and if appearing similar to a standard web page, allows the user to interact with it in much the same way they do any other html document. Due to the limitations on screen space, the system must utilize whatever space it is allocated efficiently. In order to do this, as much available screen space as possible should be given to the tree structure that will be the method of displaying the map.
No matter how much screen space is allocated, the users journey can always potentially require more space than is available. As a result, the user must be able to scroll within the map to an area of interest, although the system should refocus on the users current location within the map whenever a new link is added. Furthermore each link added to the map should provide extra details about itself where possible such as a thumbnail of its appearance as well as when and how many times it has been viewed. As mentioned earlier, the user must be able to both right, and left click on any of these links in the same way they would on a standard hyperlink on a web page, thereby reducing the systems learning curve. At this point it seems appropriate to note that the back and forward buttons must still be available to the user and the map should reflect any navigations caused by their use by refocusing on the appropriate link.
Software Interface
In order to provide any level of functionality, the system must have the ability to interact with a given web browser. The actual detailing of this interface will be entirely dependant on the type of system constructed, and whether this system implements its own browser, or runs within an existing browser. In order to meet the already specified requirements however, the system must be able not only to have access to the html document on display, but also have access to the browsers’ events, in order to determine when a new web page has been displayed.
Communications Interface
As with the software interface this will be dependent on the type of system implemented, however the system must be able to communicate with standard web servers and must therefore adhere to RFC 2616, Hypertext Transfer Protocol - HTTP/1.1).
Functional Requirements
These requirements were derived from the use cases (see Appendix A)
Map Operations
To prevent oversized maps from wasting precious screen space, the user must also be able to start a new map at any given time and/or delete sections of the map they are not using. This will be discussed in greater detail later.
As earlier discussed, the map will be implemented as a rooted tree structure. This form of map, while being faster to draw, also requires less screen space, and will therefore be a sensible format to display the users navigation.The disadvantage as noted in section 2.5 is the inability to show movement between existing links. In order to not confuse the user, the system will, as explained in section 3.1.6, refocus on the current link, and show some form of animation to clarify this movement to the user.
Browser Operations
14
A requirement of the system must allow the user to add any given link on a web page, onto the map. In order to not confuse the user between pages they have visited and those that they have not, the map must distinguish between links that have been visited and added as part of the users browse and those that have been added at the specific request of the user and not visited. In order to provide this feature intuitively to the user, the feature to add a link to the map should ideally be available from the context menu that appears in all standard browsers when the user right clicks upon a link.
To give the user the ability to make sure they follow every link from a given web page, the system should also allow the user to add every link on the current page to the map. Any feature such as this must provide a warning and allow the user to back out, as many sites contain several hundred links on a given page, and adding this much data could very easily overwhelm the user.
As a final browser-side operation, the user must not lose the ability to open links in new windows. When this occurs, the new window should begin a new map starting on that page, providing all of the same functionality provided in the original map.
Map Link Operations
In order to maintain a useful map the user must have a high level of control over individual links within the map. Without a high level of user control, the map may become cluttered or unwieldy in a short period of time, and the ability for the user to either remove or hide sections that are no longer relevant is clearly very important.In order to provide this successfully the user must have the ability so select a given link, and then perform one of a number of actions on it. Any of these actions must provide the user with a warning, and the ability to back out if they wish. They are:
Edit an existing link by either changing the URL or title of the link in question. Delete a link, whereby all of that links children remain in the map, as children of
a higher link. Delete a links children, whereby the link remains, however all links below it in
the map are erased. Delete both the link and its children, whereby the link and all of its children are
permanently erased. Move a link, whereby the link has its parent altered. In this case, all links
descending from the moved link are also moved.The map must also provide the ability to allow the user to scroll between links. As mentioned earlier, the map can always extend beyond the size of the users screen, and the system must therefore be designed to cope with this eventuality.
Additional Details
Each link item must display certain details about itself to the user. As discussed earlier, keeping the users cognitive overhead down is one of the main aims of this project. In order to meet this requirement, the details a link item displays about itself must aid the users memory. A key concept in this, inspired by the MacWarriors, TrailBlazer, (2004) project, is the use of thumbnails to remind users of sites they have visited in the past. As when searching for information a user may not be able to remember the title of visited website, the system should provide a thumbnail image of the site, which appears when the user hovers the mouse over the link for said site. In doing this, the user no longer needs to remember the title of the site they visited, and simply needs to have a basic idea of the
15
layout and colouring. Furthermore, by adding extra information such as the date and time the user visited the site, the user can easily identify places they have visited in the past.
Performance Requirements
Any system implemented must not detract in any way from the users ability to view web pages. Obviously the system will require screen space, however any space used should be minimal and should not cause the user additional efforts with extensive use of scroll bars. To aid this, the user should be able to resize the map at their convenience, and remove it altogether if they feel they do not require it, or that it is in the way.
Clearly any loss in speed caused by the system is unacceptable as speed is an important issue in web browsing. The system must therefore not cause any loss in download, or system speed. As a result of this, the system must not only implement a fast algorithm to display the map, but the algorithm of choice must use only a limited amount of screen space, and provide as clear as possible layout to prevent being a hindrance on the user.
16
4. Design
4.1 Design Overview
As the system will be entirely event driven, a state machine diagram was produced in order to get a greater understanding of events and states within the system. When coupled with the class and interface detailed below, allowed a thorough understanding of the system to be implemented. The development of the state machine diagram can be found in Appendix B, as can the final model.
4.2 Class Design
4.2.1 Tree StructureAs specified in the requirements, not only will the users navigation be held, but other possible links they may wish to visit will also be stored in a tree structure. This tree structure will be comprised of nodes each of which will contain details about a specific web page. The details these nodes must contain include:
Page URL Page title Number of visits Date and Time of last visit Children – a reference to each web page that was either visited, or added to the
map from this one. A thumbnail image of the website
They must also contain methods to: Add unique children to a given link node, i.e. search the link and if no reference
to the same web page exists then add one. Search a link node and all links that descend from it for a given link by URL. Determine the amount of space this link needs to draw its children. This will be
the key to the allocating space efficiently in the drawing algorithm. This method should check each of its children to determine which of them has the most children at a given level. This number can then be multiplied by the height of each link item displayed, to give a total height needed. Listed below is the pseudo code to discover the widest part of the tree.
getWidest(Node, currentWidest) If Node has no children Then
set currentWidest to 1 Else
For every childNode in Node Increment childsum by 1 Set call getWidest on childNode, sending currentWidest
end for If childsum is larger than currentWidest Then Set currentWidest to childsum End If End If return currentWidestEnd Function
4.2.2 Saving and LoadingIn order to store the map the system must give the user the ability to both save and load the map. The map will be stored using XML, an incredibly simple, well-documented, straightforward data format that can be read using any tool that can read a text file [Harold. E.R. W.S.Means (2001), XML in a Nutshell]. One of the main uses of XML is
17
data serialisation and this property makes it the perfect choice for the serialisation of the tree structure.
Saving
Storing the map is a relatively simple process. A string must be constructed embodying all of the information contained within the map before it is written to the file. As the tree structure will be recursive it makes sense to write a recursive procedure to cope with the string generation.
Function serialiseTree(Node)Append <NODE> to stringAppend <URL> followed by the link url then </URL>Append <TITLE> followed by the link title then </TITLE>all other details about link added here in tags same format as url and title
If Node has children thenAppend <CHILDREN> to string
For every ChildNode in NodeAppend the string returned as a result of serialisetree being sent with each child node.
End For Append </CHILDREN> to string
End If Append </NODE> to string Return stringEnd Function
As this code shows, each link node has its individual data written, before each of its children has their data added to the string. The function returns a string that can then be easily outputted to a file.
Loading
Clearly storing a tree is of little use unless it can be subsequently loaded again. Loading this information is more complicated as there is always the possibility of corruption or the user attempting to load a file of an incorrect format. Any loading routines should be able to deal with this kind of eventuality and ideally have the ability to recover partially corrupt files.
4.3 Interface Design
4.3.1 ContainersIn order to reduce the amount of coding required, the system will implement several container objects, each of which will reside within the main interface container.
System container
The main system container will be located at the base of the screen as concluded is appropriate by the literature review. It will contain both horizontal and vertical scrollbars to allow the user to manoeuvre within the map. As specified in the requirements, the system should implement a similar interface to a standard web browser. In light of this, the vertical scrollbar will always be visible, but disabled when not necessary. The horizontal scrollbar however, will not be visible unless it is required. Finally the two scrollbars will be positioned at the bottom and the right of the screen, as is standard.
The system container will also hold two separate containers, one to hold the tree structure, and a second to contain the additional details required.
18
Browser container
A browser container will be located to the top of the screen, directly above the system container, and will display the content of web pages. The exact nature of this browser window will be dependant on the implementation of the system, and it may either be a separate window to the system container, or be nested within it.
Details container
The details container will be held fixed to the top left corner of the system container, and will vertically expand and contract whenever the system container is resized. This details container will hold the additional information the system holds on each web page as listed in section 3.2.6. These details will be organised vertically with the thumbnail displayed at the top, followed by the website title, date and time of visit and finally the number of times the site has been visited.
Map container
As previously mentioned, in order for the user to be able to see the active area of the map, the entire tree structure must be movable. By placing this structure into a container we no longer have to worry about moving individual items and can focus on sliding a single container around the screen. The scrollbars will provide the user control over the movement of the map container within the screen. The background of this container will be plain white, to provide some white space around what may be fairly complicated display of links.
Change of focus animation
Section 3.2.6 discusses the effect of moving between already existing links in the map. To prevent the user from becoming disorientated, the screen must smoothly scroll between the two links. To accomplish this a simple algorithm must be produced which will move the map incrementally across the screen to the correct position.This algorithm must know the current position of the map container, as well as the co-ordinates it will be moved to.
LeftDistance = NewLeftPosition - containerMap.LeftTopDistance = NewTopPosition - containerMap.Top TopIncrement = TopDistance / 10LeftIncrement = LeftDistance / 10 While containerMap is not in position
If containerMap is not in position horizontallycontainerMap.Left=contaienrMap.Left + LeftIncrement
End ifIf containerMap is not in position vertically
containerMap.Top=containerMap.Top + TopIncrementEnd ifWait (10)
End While
The above pseudo code shows the algorithm to be implemented. Firstly it calculates the distance between the maps current position and the position it needs to be in and then sets a distance to move it each iteration. The while loop is exited as soon as the container is in position, however if it is not, the loop moves it either vertically, horizontally or both if necessary. Finally a wait of 10 milliseconds is introduced between each movement to prevent the animation occurring at a speed the user cannot see.
4.3.2 Link objectsIn order to allow the user to easily navigate between pages, each page added to the map will be represented by a link object. The user will have the ability to click each link
19
object, just as they do on a standard link in an html document. In order to abide by the colour rules specified by most web browsers, the selected link will appear against a dark blue background with white text, in the same way highlighted text appears on a web page. Non-highlighted links will be displayed in the inverse.
To further compliment the design of standard browsers the cursor will change to the pointing finger seen when links are hovered over, and additional functions will be available using a right click on the link (see section 4.3.6).
4.3.3 Tree drawing algorithmIn order to display the tree structure a suitable algorithm must be designed. As specified in the requirements this must give a clear layout and not decrease the users browsing speed.
As discussed in the literature review, different areas of the screen have different values to the users perception. As the system is a navigational aid it does not need to be eye catching as it will be there at the users request. As such it should not be placed in a high value area of the screen such as the top left and would be more reasonable located towards the bottom or right.
The decision was made to locate the system below any visible web content, giving more lateral, but less vertical space. The reasons for this are as follows:
The majority of websites are displayed in a format such that the user scrolls from the top of the page to the bottom, as opposed to from the left to the right. Therefore, by adding the system below any web content, the user is not presented with an extra, horizontal scrollbar, but simply has to scroll further in an up/down direction to view all content.
English speakers read from left to right first, then top to bottom. Therefore by adding the system to the right of any web content would mean either the system would waste precious screen space above and below the links, or would have to write text from top to bottom.
4.3.4 Displaying additional informationAs discussed in the requirements each link should display additional details about itself. These details will include a thumbnail image of the site in question, as well as the date it was last visited, and the number of times if has been viewed.
This additional information will be displayed to the right of the tree layout, and will by default show details on the current page. However when a link is hovered over this extra information will be updated to show active link. When a mouse over event occurs on a link item, the mouse cursor should alter to the familiar pointing hand as is seen on standard html links.
4.3.5 Saving and LoadingIn order to be able to return to a previously used map, the user must be able to both save and load maps. In order to reduce the users learning curve, as discussed in the requirements document, the save and load dialogs will appear in the same format as they do in other applications.
20
4.3.6 MenusAll additional functions should be made available to the user using a menu driven system. These menus should appear when the user right clicks on a given link and should give the user the following options:
Start a new map Save map Load map Delete map from here Delete this link
In addition to these options, the standard options shown when the user right clicks on a standard html links should appear. These additional choices are:
Open Open in new window Copy Shortcut Add to favourites Properties
However their implementation is not essential.
21
5. Implementation
In order to keep this section from simply becoming a catalogue of classes, only interesting features will be discussed in any detail. It is therefore important to note that this chapter is far from an exhaustive list of all the features of the system.
5.1 Class StructureVisual Basic is not entirely object orientated and therefore the overall class structure for the system will reflect this. The interface will be kept as separate as possible from the data structure it is displaying (see section 5.2). This will be accomplished using a combination of Visual Basic forms, modules and class modules. The main form (frmContainer) will be the implementation of the container discussed in section 4.3.1, which will then hold the other containers (see section 5.3). A module (modBand), is used to interact with Internet Explorer (see section 5.5), and this module will pass events such as resizing and closing, as well as navigation events to and from our frmContainer object. The frmContainer object will therefore have total control over the system and it is from here, where all events will be handled.
5.2 Tree structureAs discussed throughout the requirements and design, the tree will be rooted. As such, a reference to the root link must exist so access to the rest of the tree is possible. As well as a reference to the root link, there must also always be a reference to the current link on display. This then allows the system to refocus on this current link, and highlight it in a different colour to other links on display. The root link, current link, and all of their children are of class clsLink. This class contains all of the methods discussed in the design and the source code for this can be found in Appendix E.
An interesting feature of this class is its recursive implementation. Every clsLink can contain references to more instances of the clsLink class. To store these children each clsLink object implements a collection of clsLinks known as Children. This collection was made public to reduce code, as many objects require access to the various methods the collection object provides.
Each clsLink also provides methods for setting and retrieving the thumbnail, setting and retrieving the URL and title, as well as discovering the widest part of the tree below itself (see section 4.2.1). Most importantly each clsLink has a method that lets the user search through its children, either by number (for communication with the interface) or by URL. These methods are of key importance, as without them the user interface would be unusable. This is due to the implementation of the link interface object that as discussed earlier must be referenced to a link within the tree. In order to accomplish this, each link object is allocated an unique id when it instantiated, which the interface link object uses as its array index.
22
5.3 User Interface
5.3.1 Overall DesignAs discussed in section 4.3.1, the interface is comprised of three containers. Visual Basic does not have a container implementation as such, and as it is not strictly object orientated its is not possible to create one. However, certain VB objects can be used to “contain” others, and it is this effect that will be utilised. In this case, the main form window will be used as the super container, and two picture boxes will reside within it. These picture boxes labelled picDetails and picFrame are described later; however figure 5.1 showstheir layout along with the layout of the two scrollbars named HScroll and VScroll.
Figure 5.1 The layout of container objects within the system
It is important to note that the above figure only shows the relative positioning of each container and that in reality, frmContainer will have no visible screen space, as it will all be used up by both picDetails, picFrame and the two scrollbars.
5.3.2 PicFrame Container
Link Objects
As Visual Basic is not entirely object orientated, the graphical objects used to represent the tree cannot be combined into the tree structure. While this has the advantage of clearly separating the interface and the working end, it means that all link objects will have to be stored in a separate linear data structure, and not in the tree structure where the information they embody is held. In order to link these graphical objects and their counterparts (see section 5.2), the links will be held in an array is the unique id given to their clsLink counterparts.
The links used to represent the tree will be VB label objects, which have left and top properties that can be used to set their positions. They also contain a caption setting for the link title and have a mouse down event that can be captured and used to fire both the menu system discussed in section 5.3.5 and change the page being displayed by the browser. Whenever a user places the mouse over one of these links, not only will the mouse cursor change to the standard pointing hand, but the picDetails container will change its content to match that of the link being hovered over.Using the link objects “AutoSize” property the link can be forced to use the minimum amount of space required to show the current caption, and helps prevent the system from wasting its limited space. VB line objects will also be referenced in a similar manner to show the users’ travel between various links.
frmContainer
picDetails picFrame
23
Tree Drawing Algorithm
The tree-drawing algorithm featured in section 4.2.1 must iterate through the tree structure and draw each link as mentioned above in the correct position. In addition to the drawing the tree, the algorithm must pass the dimensions of the completed tree to the scrollbars so that they may adjust their scroll settings, and must also ensure that the currently displayed web page has its link visible and highlighted.The algorithm will embody two separate parts, the first to draw the initial “root” link, and the second to draw all subsequent links. This splitting of the task is necessary, as only the
initial “root” link will have no line object associated with it, and means that unnecessary details do not have to be continually passed to the algorithm every time the tree must be drawn.
Figure 5.2 Output from the tree drawing algorithm
5.3.3 PicDetails Container
Figure 5.3 PicDetails layout
5.3.4 ScrollbarsThe two scrollbars shown in Figure 5.1 will be the users method of moving the map around the screen. Whenever any scrollbar events occur the picFrame container is moved in the relevant direction.
Private Sub HScroll_Change()picFrame.Left = HScroll.ValueEnd Sub
Private Sub HScroll_Scroll()picFrame.Left = HScroll.ValueEnd Sub
As the above code shows whenever any of the scrollbars events are fired, the picFrame container is moved to a new location, dependant on the new value of the scrollbar. The vertical scrollbar is implemented in a similar manner.
Page Title:
Date last visited:
Number of times visited:
Thumbnail image
Highlighted link
Google search:…..
Google search options
Google News
24
5.3.5 Context MenusSection 4.3.4 discusses the requirements of the context menus. The implementation of these menus is very simple and will not be discussed here. The methods the context menu provides access to are however, very important.
In order to discover clsLink containing the details of URL, thumbnail etc, a search is performed on the root link. The code below shows the entire mouse down event for one of the link objects. It firstly sets thisLink as the link just selected using root.searchByNumber(). The mouse button clicked is then determined and either the context menu is shown, or the location specified by thisLink is navigated to.
Private Sub thisLabel_MouseDown(Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single) Dim thisLink As clsLink Set thisLink = root.searchByNumber(Index) Set currentLink = thisLink If Button = vbRightButton Then thisFrmMenu.Index = Index thisFrmMenu.setMove Not root.compareURL(thisLink) thisFrmMenu.setCollapsed thisLink.Collapsed thisFrmMenu.setShrink thisLink.Shrink PopupMenu thisFrmMenu.mnuOptions Else thisLink.ThumbNailSet = False thisLink.Visit IEWindow.navigate thisLink.getURL End IfEnd Sub
Start a new map
To start a new map, the system simply creates a new root object, and sets its properties to match those of the current page being viewed. The map is the redrawn using the new rootobject, which of course has no children and is the only link shown.
Dim newRoot as new clsLinknewRoot.setLink (currentLink.getURL, currentLink.getTitle)set root=newRootdrawTree
Delete map from here
As with starting a new map, this function is relatively simple. It uses the parent property each clsLink is provided with, and simply deletes the selected link from its parents children collection. The map is then redrawn.
Public Sub DeleteEntire() Parent.DeleteGivenChild Me Set frmContainer.currentLink = ParentEnd Sub
Delete this link
This function is slightly more complex than the two which preceed it. It only deletes the selected link, and shuffles its children up to its parent. This is accomplished by iterating thorough all of its children and adding them to its parent. Its own reference is then deleted and the map is refreshed.
Public Sub DeleteSingle() Dim thisChild As clsLink 'switch all of my children to my parent For Each thisChild In Children Parent.addChild thisChild Next 'then delete me Parent.DeleteGivenChild Me Set frmContainer.currentLink = ParentEnd Sub
25
5.4 Thumbnail Processing
An important feature briefly mentioned in section 4.3.2 of the design is the cataloguing of screen shots of each web page visited. Clearly a picture of the entire screen was not required therefore the image captured must be only of the web page being viewed and not of navigational controls (including this system) or any other open windows.
Using Windows API functions, the currently displayed web page could not only be captured as an image, but also compressed to an appropriate size for use as a thumbnail. Firstly the correct window must be found. In all Windows operating systems each open window is allocated a number (held as a long) known as a HWnd. Each window may contain other windows that also have unique HWnd’s. Using this unique identifier it is possible to discover each windows name, and that the title of the current internet browser window is “Internet Explorer_Server”. By passing this identifier to a GetScreenSnapshot function only the appropriate window has an image captured, which can then be compressed, passed to the tree structure and then displayed upon request.
5.5 Microsoft Internet Explorer
5.5.1 OverviewImplementing the system as a plug in for Internet Explorer will give the system total control of the browser, including the ability to capture events and properties raised by a given web page. This will also allow the user to add entries into the explorer context menu (this is the menu which appears whenever a user right clicks on a web page).
Creating the system as a Microsoft Internet Explorer plug in means that the system will not be available to all, although as a prototype this is not really a major issue. Furthermore, from the users position, embedding the system into Internet Explorer means a far shallower learning curve, as most web users are familiar with its interface.
5.5.2 C++ ClassesIn order to run the application within Internet Explorer, a common interface had to be created. This interface was distributed freely with the book Visual Basic Shell Programming by J. P. Hamilton, and will therefore not be discussed any further.
5.5.3 The Windows RegistryIn order to implement this plug in various modifications to the Windows registry had to be made. Primarily these modifications included the generation of a unique id, (known as the CLSID). The main reference to this is included in the CLSID list in the [HKEY_CLASSES_ROOT\CLSID\] section of the registry. It is here where the CLSID is associated with the compiled path of the system, and the type of object the system implements is defined.
The context menus featured in section 5.5.7 also required modifications to the registry but these will not be discussed here, as their implementation is very similar. See Appendix Efor all registry changes required.
26
5.5.4 The Band ObjectAs specified in section 4.3.1 the system container (frmContainer) should be located at the bottom of the screen below the browser window. In order to interface correctly with the Internet Explorer instance, the main system window must implement a band object.There are two types of band object that can be implemented to reside in explorer. The first being an explorer band, and the second a communication band. The explorer band type can be immediately discounted, as it is a vertical bar, which is shown to the left of the browser window. The system container must therefore implement a communications band object that is displayed at the base of the explorer window. See figure 5.3.
Figure 5.3 Communication Band implementationIn order to implement such an object, frmContainer must have a class (clsContainer) that implements this interface. The details of this will not be discussed at great length here and the source code can be found in Appendix E.
5.5.5 The Internet Explorer ObjectSetting a reference to the active Internet Explorer object allows the system to capture events occurring within the browser, as well as capturing the Document Object Model (see section 5.5.6).
The ability to capture the OnDocumentComplete() and BeforeNavigate2() events, allowed the system to be notified when the user visited a new website, and not only allowed the context menus to be implemented appropriately (see section 5.5.7) but for the system to catch new web pages as they are displayed and create a new link on the map for them.
An interesting property of the OnDocumentComplete() event, is that it is not only fired when a web page is completed, but also every time a frame of that given web page is downloaded. To prevent this from cluttering the map with a link for each frame, a simple downwards counter was implemented, so only the final frame had a link added.
Set HtmlDoc = IEWindow.document If FrameCount = -1 Then FrameCount = HtmlDoc.frames.length Dim i As Integer
If FrameCount = 0 Then AddLink HtmlDoc.URL, HtmlDoc.Title FrameCount = -1 Else FrameCount = FrameCount - 1
Communication Band
27
End If
5.5.6 Document Object ModelThe Document Object Model (DOM) is a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. [World Wide Web Consortium. (2004) www.w3c.org].Access to the DOM was gained using the following code:
Set HtmlDoc = IEWindow.document
Where IEWindow is the current Internet Explorer window as specified in section 5.5.5. Using this HtmlDoc object allows easy extraction of any part of a web document. In our case title, URLs and link objects. In order to extract the links from the html document, the following code was used:
Dim LinkCount as IntegerDim HtmlLinks As IHTMLElementCollection ' A collection of links from the
DOMDim HtmlLink As New HTMLLinkElement ' A single link element entry in
the DOM Set HtmlLinks = HtmlDoc.links ' Define the links on the html domFor LinkCount = 0 To HtmlLinks.length - 1
Set HtmlLink = HtmlLinks.Item(LinkCount) 'we now have a link object as specified by the DOM, to do as we wish with
Next LinkCount
5.5.7 Context MenusA second context menu, entirely separate from the one active within our containers is the Internet Explorer menu. By adding entries into the registry (see section 5.5.3) functionality could be added to the standard menu. The two entries added; “Add this link to map” and “Add all links to map”, allow the user to simply select a link and perform these actions in the same way they would any other action within Internet Explorer. In order to then pass this information from Internet Explorer to the band object (our system), a short web script was written for each action. This following script is executed when the selects “Add this link to map”. The script for “Add all links to the map” is similar.
<SCRIPT LANGUAGE="JavaScript" defer> var parentwin = external.menuArguments;var doc = parentwin.document;
var innerText = window.external.menuArguments.event.srcElement.innerText;
var GRlink = window.external.menuArguments.event.srcElement;if (GRlink == "[object]") {var GRlink = window.external.menuArguments.event.srcElement.parentElement;}if (GRlink == "[object]") {var GRlink = window.external.menuArguments.event.srcElement.src;}if (GRlink == null) {var GRlink = window.external.menuArguments.location;
}//i can use vb to check the web address, and only navigate if it has no -addcontextlinkvar GRurl = GRlink + "-addcontextlink"+innerText + "-contextlinktext";
parentwin.location.href = GRurl;</SCRIPT>
This script takes the URL of the link selected, appends onto it the text “-addcontextlink” followed by the title of the link and then “-contextlinktext”. The script attempts to load this string as a web page. Obviously this would fail as it ist correctly formatted, however,
28
as is discussed in section 5.5.5, the BeforeNavigate2 event of the IE object has been caught and can therefore prevent the page from being loaded. This event can now take the URL sent, and extract the title and URL of the new link to add.
29
6. System Testing
The system will need to be tested on two levels; primarily the system must be tested to ensure that it is error free and complete with respect to the requirements. Secondly the system must be tested on a selection of users to determine whether or not it has accomplished its goal as set out in section 2.7; to reduce user disorientation and cognitive overhead while web browsing.
6.1 System Testing
6.1.1 OverviewIn order to comprehensively test the system the main outputs of the system must be defined with respect to the requirements, and then compared with the actual outputs.The main abilities the system must present are:
The ability to show the users path through different websites The ability to edit this representation of the users path The ability to animate movement between different links on the representation The ability to store additional information about each site visited. The ability to store and retrieve the representation of the users path. These capabilities were tested using a series of black and where appropriate white
box tests upon the user interface. Details of this testing can be found in Appendix D and a discussion of the results are described in the following section (6.1.2)
6.1.2 Errors RaisedAs can be seen from the tests detailed in Appendix D several key errors were raised in the programs implementation. These errors, while not fixed in the final prototype are discussed here, and ways of repairing them are also detailed.
B.1 Test 1
This error was caused by the use of a precompiled component, the Visual Basic Scrollbar. The error, while not ceasing the operation of the program is a critical one, as it prevents the user from navigating through the map successfully.The error is caused by an integer overflow on the scrollbar objects maximum or minimum value property.
This error also brought to attention a similar error, caused by the positioning of the container objects detailed in chapter 4. This error is caused in exactly the same fashion, and is raised when the size or the positioning of the container is set to a value outside of the integer boundary.
Solutions to both of these errors would be to implement new objects to handle positioning, where the positional values are stored as long integers.
30
Another possible solution could involve breaking the map up into smaller areas, and only drawing a single area at a time, thus eliminating the need for large variable sizes for positioning.
Finally, the concept of a fish eye browser, as discussed in section 3.1.6, would eliminate the error, as all areas of the map would be visible on screen at a time (even if compressed to a smaller size), and thereby all positional values would fall within the integer range.
B.2 Test 2
This test brought up another error. Again while being neither a critical error causing the system to crash, nor a constant error, it is still worth noting. The error in question is caused under two circumstances and involves the mechanism for capturing an image of the web page being viewed. The first circumstance for failure is when another window is in front of the web browser. In this case an image of the window in front is taken. This is caused by the way in which the windows operating system takes any form of screenshot. The second cause of failure is when a web page is downloaded and the OnDocumentComplete() method is fired before the page has been rendered. Although this does not occur often, it causes the image taken to be of a clear white page and not the web page on display.To rectify these problems extensive changes would need to be made to the way in which the screenshots are taken, possibly including a entire rewrite of the screenshot taking methods built into windows.
6.2 User Testing
6.2.1 UsersIn order to conclude whether or not the system is successful in its goals, it is important to test it on a range of users. The users selected for testing, as specified in section 3.2.2 should be experienced web users for whom the system has been designed to aid. Testing on a wider audience was deemed unnecessary, as they are unlikely to require much of the functionality provided.Ideally testing would have been undertaken on a far larger group or twenty or more, however, such a group was unavailable and therefore the testing done was somewhat limited.The user testing will aim to uncover areas of which further work can be done in this field to improve the prototype, and these improvements will be discussed in the section 7.1.
6.2.2 Testing StrategyThe testing strategy to be used is that of a co-operative evaluation. Monk et al (1993) see the defining features of a co-operative evaluation as:
Users work through tasks selected by the designer Users work with a prototype or simulation Users think aloud and ask questions, whilst the designer may also ask the user
questions. The designer looks for unexpected behaviour and comments on the user interface
from the user.User testing was performed on four users, and the results can be found in Appendix D. Commentary on the issues raised can be found in the conclusion (section 7.1).
31
7. Conclusion
7.1 Further work
The two forms of testing undertaken clearly showed several areas where future improvements can be made. The comments provided by users after having conducted the co-operative evaluation highlight key areas where improvements in the requirements specification could be made, leading to a more usable system.Issues raised by users of the system, range from easily implemented minor grievances through to larger usability problems.
One of the biggest issues raised was that of the sheer quantity of links added, when the “Add all links to map” option was chosen. Users found this made their traversal of links much harder, and that it was often hard to find their way back to the page from which they added the links. To improve this situation a combination of alterations could be put into effect. Firstly the “Add all links” method could simply add the first n links, onto the map, with the option to expand this to more at the users request. Secondly the positioning of parent links could be alongside their first child link, as opposed centred against them. This would have the effect of positioning the “root” link, at the top left of the map container, making it always easily accessible.
Another avenue for improvement suggested by users, would be the categorisation of different web pages into different maps. This form of system could allow the users to maintain several searches at once, each with an associated map. Links on these individual maps would have the same functionality at the system created and users would be able to interchange links between them freely.
The largest usability problem users had was when moving links around the map. Several users complained that it was not obvious where on the map they could drop the link being moved, and whether or not it was over an appropriate area. A simple solution to this could be a simple visual clue, to tell the user when they can drop the link.
Further improvements and added functionality to improve the users experience, could include the facility to automatically retrieve all web pages that have a link on the map. This would eliminate the time users spent waiting for pages to be downloaded, and could significantly increase browsing speed, especially either on slower connections, or on graphic intense sites.
Another improvement could be the recognition and the potential deletion of pages that are no longer available. This feature could check to see if a site is still online, or whether a page has expired and notify the user or delete the link before they waste time navigating to it.
7.2 Final RemarksThe use of the Internet to perform directed searches for either research or leisure is an area that is growing rapidly. At present, when a user wishes to maintain several trains of thought they must either maintain bookmarks, use the history function, or run multiple browsers simultaneously.
32
The scope of this project was to provide a tool, which while aiding the user undertaking a directed search did not create extra tasks for them to manage.
In order to fulfil these goals, the concept of mapping the users navigation through websites and displaying this as a tree structure was introduced. This map structure would then allow the user to maintain several trails of thought, and obtain additional information about websites they had already visited.
The system implemented was a map in the form of a rooted tree structure. This map was automatically kept up to date with the users movements as they traversed a web site, allowing them to return to previous ideas at the click of a mouse. The system not only allows users to add any given link on a page to the map without visiting it, but allows the user to store the map and return to it at a later time. Additional information about each page the user visits is also stored, allowing the user to check the dates and times they visited sites, as well as obtaining a small screen shot of the site viewed.
The completed system did achieve the key objectives set out within the literature review. The user testing performed shows that users found the system a useful tool in searching and that it not only helped them maintain their context, but also reduced their usage of the bookmark and history features. Furthermore users were found to no longer be as dependant on repeated use of the back button, and instead were able to simply select the specific page they wished to view. Finally the use of screenshots allowed the end user to select a site by simply scanning the mouse over the links thereby reducing the number of sites accidentally navigated to, and allowing the user to remember where they had been.
33
8. Bibliography
Conklin. J. (1987) Hypertext: an Introduction and survey, IEEE Computer, 20-7, 17-41
Faulkner. F. (1998) The essence of human computer interaction
Tufte. E (1990). Envisioning Information
Retrofit of flat panel color displays in the F16A/B. In Proceedings IEEE/AIAA 11th Digital Avionics Systems Conference (Seattle, Washington, 1992), pp.323-328
Hartson. H (1993) Developing User Interfaces
Preece. J. (1993) A guide to Usability: Human Factors in Computing
Catledge. L.D. Pitkow. J.E. (1995) Characterizing Browsing Strategies in the World-Wide Web, Third International World-Wide Web Conference: Technology, Tools and Applications, Darmstadt, Germany.
Inder. R. Kilgour. J, Lee. J, (1998) Automatic Generation of Diagrammatic Web Site Maps, Human Communication Research Centre, University of Edinburgh
Wittenburg. K. Sigman E. (1997). Visual Focusing and Transition Techniques in a Treeviewer for Web Information Access
Healey. C.G. (1996) Choosing Effective Colours for Data Visualisation
Newfield. D. Sethi. B.S. Ryall. K. (1998) Scratchpad: Mechanisms for Better Navigation in Directed Web Searching
Shubin. H. Meehan. M.M. (1997) Navigation in Web Applications, Interactions
Utting. K. Yankelovich. N. (1989) Context and Orientation in Hypermedia Networks, Brown University
Jones. S. Cockburn. A. (1996) A Study of Navigational Support Provided by Two World Wide Web Browsing Applications
Park. J. Kim. J. (2000) Effects of Contextual Navigation Aids on Browsing Diverse Web Systems
Zeiliger. R NESTOR, The Web Browser and Cartographer,
http://www.gate.cnrs.fr/~zeiliger/nestor (10/12/03)
Nielsen. J. (1999) Designing Web Usability
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specification
RFC 2616, Hypertext Transfer Protocol - HTTP/1.1
RFC 1866, Hypertext Markup Language - 2.0
34
MacWarriors, TrailBlazer, (2004)
http://www.acm.uiuc.edu/macwarriors/projects/trailblazer (27/03/04)
Furness. G. (1986) Generalized fisheye views, CHI '86 Conference on Human Factors in Computing Systems, pages 16-23
Henderson D. A. Card. S. K Rooms (1986) The use of multiple virtual workspaces to reduce space contention in a window-based graphical user interface. ACM Transactions on Graphics, 5(3):211-243.
Shneiderman. B. (1986) Designing the User Interface – Strategies for effective Human-Computer Interaction
Harold. E.R. W.S.Means (2001), XML in a Nutshell
Hamilton J. P. (2000) Visual Basic Shell Programming
World Wide Web Consortium. (2004) www.w3c.org (18/03/04)
Monk. A. Wright. P. Haber. J. Davenport. L (1993) Improving your human-computer interface: A practical approach. New York: Prentice-Hall.
Dix. A. Finlay. J. Abowd. G. Bearle. (1997) R. Human Computer Interaction (second edition)
Oborne D.J. (1985) Computers at work: a behavioural approach
www.devx.com
www.vbcity.com
http://www.mozilla.org/ (15/02/04)
http://www.w3schools.com/browsers/browsers_stats.asp visited on (18/03/04)
35
Appendix A
Use Case Scenarios
System Startup
1. The user starts the system. A new blank map is automatically created and displayed on screen.
2. The user then begins looking at websites3. Links are added to the map as the user browses
Adding a link, already displayed on a web page
1. User right clicks on link in web page2. System presents a menu with available options on it.3. User selects “Add to Map”4. A new link is generated and added to map
Adding a new link
1. User right clicks on link on map2. System presents a menu with available options on it3. User selects “Add new link”4. System prompts user to fill in link title and url.5. A new link is generated and added to the link originally clicked on6. A new link is displayed on map
Deleting a single link
1. User right clicks on link they wish to delete2. System presents a menu with available options on it3. User selects “Delete-> Delete This Link”4. System asks user for confirmation5. System deletes given link and shuffles all of that links children to the given links
parent.6. System displays the updated map
Delete an entire sub tree of links
1. User right clicks on link they wish to delete2. System presents a menu with available options on it3. User selects “Delete -> Delete entire sub tree”4. System asks user for confirmation5. System deletes given link and all of its children6. System displays the updated map
Adding a page full of links
1. User right clicks on web page 2. System presents a menu with available options on it3. User selects “Add all links to context map”4. System asks user for confirmation5. System adds all links on current web page to the map6. System displays the updated map
36
Hiding a selection of links
1. User right clicks on parent of links they wish to hide2. System presents a menu with available options on it3. User selects “Collapse”4. System adds tick next to “Collapse” on menu5. System hides all the children of this link.
37
Appendix B
State Machine Diagrams The following diagrams show the state machine model in various forms as it was constructed. Figure B.6 is the final version, upon which the implementation is based.
Figure B.1 State machine diagram modelling browser events and map alterations
Figure B.2 Extension of figure B.1 showing events allowing user to add links manually.
URLChange Add link
Valid URL
On Navigate
Do: Check URL
Document Complete
Do: Download and show page
Redraw Tree
Do: draw tree
Waiting
Do: display web page
Invalid URL- add link(s)
URLChange
Add link
Valid URL
On Navigate
Do: Check URL
Document Complete
Do: Download and show page
Redraw Tree
Do: draw tree
Waiting
Do: display web page
38
Figure B.3 Extension of figure B.2, showing the use of mouse over events to display additional details.
Figure B.4 extension of B.3, showing users’ ability to edit links
Mouse off link
Invalid URL- add link(s)
URLChange
Add link
Valid URL
On Navigate
Do: Check URL
Document Complete
Do: Download and show page
Redraw Tree
Do: draw tree
Waiting
Do: display web page
Update scrollbars
Do: calculate new scrollbar values
Update details
Do: change details displayed
Mouse over link
Mouse off link
Invalid URL- add link(s)
URLChange
Add link
Valid URL
On Navigate
Do: Check URL
Document Complete
Do: Downloadand show page
Redraw Tree
Do: draw tree
Waiting
Do: display web page
Update scrollbars
Do: calculate new scrollbar values
Update details
Do: change details displayed
Mouse over link
Cancel
OK
Add/move/delete link
Checking
Do: Confirm with user
39
Figure B.5 Showing save events with user input
Cancel
Unsuccessful save
OK
Invalid path
Valid path
Cancel
Save tree Checking
Do: Get path from user
Inform
Do: display error message
Inform
Do: display error message
Saving
Do: Save Map
Mouse off link
Invalid URL- add link(s)
URLChange
Add link
Valid URL
On Navigate
Do: Check URL
Document Complete
Do: Download and show page
Redraw Tree
Do: draw tree
Waiting
Do: display web page
Update scrollbars
Do: calculate new scrollbar values
Update details
Do: change details displayed
Mouse over link
OK
Add/move/delete link
Checking
Do: Confirm with user
40
Figure B.6 Final state machine diagram showing all user input, and browsing events.
Mouse over link
OK
OK
Valid path entered
Invalid path entered
Cancel
Cancel
OK
Add/move/delete link
URL = Add link(s)
Unsuccessful save
OK
Invalid path
Successful save
Valid path
Cancel
Save tree Checking
Do: Get path from user
Inform
Do: display saved message
Inform
Do: display error message
Inform
Do: display error message
Saving
Do: Save Map
On Navigate
Do: Check URL
Document Complete
Do: Download and show page
Redraw Tree
Do: draw tree
Update scrollbars
Do: calculate new scrollbar values
Checking
Do: Confirm with user
Update details
Do: change details displayed
Load treeChecking
Do: Get path from user
Inform
Do: display error message
Waiting
Do: display web page
41
Appendix C
System TestingDefinitions:
Add link (navigation) - A link has been added to the map automatically due to the user changing web page.Add link (manual) - A link has been added to the map manually due to the user selecting and clicking “Add to map”Add all links – The user has selected “Add all links to map”Move link – A link has been moved on the mapDelete link- A link has been deleted from the mapLink Added – A link being added to the mapWarning message – the user is warned and given the option to back out.Focus changed – animation showing movement to the currently focused linkScrollbars updated – The scrollbars being correctly resized and positioning in response to the map being altered in dimension of current focus.
Black box testing
B.1 Test 1This initial test was undertaken to test whether the system was able to show the users path through different websites. In this test the system was run for an extended period of time, with the tester traversing through a large website.
Input Expected Actual Pass/FailAdd link (navigation)
Link Added, focus changed, scrollbars updated
Link Added, focus changed, scrollbars updated
Pass
As above (x25)Add link (navigation)
Link Added, focus changed, scrollbars updated
Link added, focus changed Fail
Table B.1.1
This error occurred when the map size exceeded a certain value. The error did not cause a total system failure, however it did cause a large section of the map to become unreachable. Ways of treating this error are detailed in section 6.1.2.
B.2 Test 2This test was performed to check the ability of the user to modify the map, by manually adding, deleting or moving links.
Action Input Expected Actual Pass/Fail1 Add link
(navigation)Link Added, focus changed, scrollbars updated
Link Added, focus changed, scrollbars updated
Pass
2 Add link (manual) Link Added, scrollbars updated Link Added, scrollbars updated Pass
3 Add link (manual) Link Added, scrollbars updated Link Added, scrollbars updated Pass4 Add link (manual) Link Added, scrollbars updated Link Added, scrollbars updated Pass
5 Add link (manual) Link Added, scrollbars updated Link Added, scrollbars updated Pass6 Delete link Warning message, link deleted,
scrollbars updatedWarning message , Link deleted, scrollbars updated
Pass
7 Move link Warning message , Link moved, scrollbars updated
Warning message , Link moved, scrollbars updated
Pass
42
8 Add all links Warning message, links added, scrollbars updated
Warning message, links added, scrollbars updated
Pass
9 Start a new map Warning message , whole map deleted, scrollbars updated, new root link created
Warning message , whole map deleted, scrollbars updated, new root link created
Pass
Table B.2.1
This test worked exactly as specified, proof of this is provided in the format of screen shots after each action has been taken.
Figure B.2.1- result of action 1
Figure B.2.2 – result of action 2
Figure B.2.3 – result of action 6
Figure B.2.4– result of action 6
43
Figure B.2.6 - Result of action 7
Figure B.2.7 - Result of action 8
Figure B.2.8 – Result of action 8
B.3 Test 3This test was performed to check whether additional information was being stored about each site visited, and that this information was accurately displayed back to the user. These action should also occur in Test 1 (B.1) but it was felt that separating them would provide a clearer overview.
Input Expected Actual Pass/FailAdd link (navigation)
Screen shot taken and additional information shown
Screen shot taken and additional information shown
Pass
Add link (navigation)
Screen shot taken and additional information shown
Additional information shown Fail
Table B.3.1This error while not causing a total system failure does not comply with the requirements. The cause and solutions for this error are detailed in section 6.1.2.
B.4 Test 4This test was performed to test the animation between links.
Input Expected Actual Pass/FailAdd link (navigation)
Movement between current link and new link added
Movement between current link and new link added
Pass
Add link (navigation)
Movement between current link and new link added
Movement between current link and new link added
Pass
Back Movement between current link and old link
Movement between current link and old link
Pass
44
Add link (navigation)
Movement between current link and new link added
Movement between current link and new link added
Pass
Back Movement between current link and old link
Movement between current link and old link
Pass
Add link (navigation)
Movement between current link and new link added
Movement between current link and new link added
Pass
This testing was done comprehensively over an entire traversal of a website, and not in just a simple linear movement. All tests done in this area were successful.
White box testing
B.5 Test 5In order to test the ability of the system to store and retrieve the representation of the users path, a white box test was undertaken to discover whether the file outputted by saving the map was as expected. A white box test was decided on for data serialisation, as it is one of only a few functions upon which the user interface has no influence and is clearly an important section of the program.
Public Function writeLink(root As clsLink, aTab As String) As Boolean‘aTab is holder for the number of tabs to display each child at, this‘is included to make the resulting file readable with a text editor Dim thisLink As clsLink Dim Result As Boolean Result = True Print #1, aTab & "<NODE>" Print #1, aTab & "<URL>" & root.getURL & "</URL>"
Print #1, aTab & "<TITLE>" & RemoveComma(root.getTitle) & "</TITLE>"
Print #1, aTab & "<CURRENTLINK>" & root.compareURL(frmContainer.currentLink) & "</CURRENTLINK>"
Print #1, aTab & "<COLLAPSED>" & root.Collapsed & "</COLLAPSED>" Print #1, aTab & "<AUTOUPDATE>" & root.AutoUpdate & "</AUTOUPDATE>" Print #1, aTab & "<DATESTAMP>" & root.DateStamp & "</DATESTAMP>"
Print #1, aTab & "<VISITEDCOUNT>" & root.VisitedCount & "</VISITEDCOUNT>"
If root.Children.Count > 0 Then Print #1, aTab & "<CHILDREN>" For Each thisLink In root.Children aTab = aTab & vbTab Result = writeLink(thisLink, aTab) aTab = Left(aTab, Len(aTab) - 1) Next Print #1, aTab & "</CHILDREN>" End If Print #1, aTab & "</NODE>" writeLink = ResultEnd Function
In order to force the above function into running through every line of code the clsLink provided must have at least one child. In passing a instance of clsLink of this nature, every line of code will be executed.
Input will be an instance of clsLink with the following properties:
URL: http://www.google.co.ukTitle: GoogleCurrentLink: FalseCollapsed: FalseAutoUpdate: TrueDateStamp: 09/05/2004 17:41:01VisitedCount: 2Children:
URL: http://news.google.co.uk/</Title: Google newsCurrentLink: True
45
Collapsed: FalseAutoUpdate: TrueDateStamp: 09/05/2004 17:41:05VisitedCount: 1
The resulting output of this should be:<NODE><URL>http://www.google.co.uk/</URL><TITLE>Google</TITLE><CURRENTLINK>False</CURRENTLINK><COLLAPSED>False</COLLAPSED><AUTOUPDATE>True</AUTOUPDATE><DATESTAMP>09/05/2004 17:41:01</DATESTAMP><VISITEDCOUNT>2</VISITEDCOUNT><CHILDREN>
<NODE><URL>http://news.google.co.uk/</URL><TITLE>Google News U.K.</TITLE><CURRENTLINK>True</CURRENTLINK><COLLAPSED>False</COLLAPSED><AUTOUPDATE>True</AUTOUPDATE><DATESTAMP>09/05/2004 17:41:05</DATESTAMP><VISITEDCOUNT>1</VISITEDCOUNT></NODE>
</CHILDREN></NODE>
This is exactly the string returned by the function and we can therefore conclude that this function is correct.
46
Appendix D
User Tasks:
1. Search for: “Cheap CDs”
2. Add seveal links you deem relevant to the map
3. Go to the second page of results.
4. Add 2 more links you deem relevant
5. Delete second search page from map, allowing children to shuffle up
6. Look at the links you have added
7. Close the browser
8. Reload your map from the default path (C:\default.map)
9. Delete links some links which no longer interest you
10. Move a link that is not directly associated with the search engine, so it is.
11. Add all links on a page to the map.
12. Go back to search engine
13. Start a new map (and save)
47
Post task questionnaire:1. What did you find hard to use?
2. What did you find easy to use?
3. Did everything perform as you expected it to?
If no, what?
4. What would you change?
5. Did you think the system:a. Helped you navigate between sitesb. Made it harder to navigate between sitesc. Made it harder to view websitesd. Speeded up your searche. Slowed down your searchf. None of the above.
6. Why?
48
Questionnaire Results (1):
Post task questionnaire:1. What did you find hard to use?
Number of links added by “Add all Links” was hard to navigate. Hard to find starting point when lots of links
2. What did you find easy to use?
Navigating quickly between added links from searches
3. Did everything perform as you expected it to? Yes
If no, what?
4. What would you change?
When lots of links on map, only show the first n. Then allow the user to expand that if they wish to see more
5. Did you think the system:a. Helped you navigate between sites - markedb. Made it harder to navigate between sitesc. Made it harder to view websitesd. Speeded up your searche. Slowed down your searchf. None of the above.
6. Why?Didn’t speed up search but was useful to keep track of where you’d been/intend to go etc…
49
Questionnaire Results (2):
Post task questionnaire:1. What did you find hard to use?
Found it hard to find the save and load map functions on the menu. Didn’t originally realise that they had to be selected from the map area of the screen, and not elsewhere
2. What did you find easy to use?
Navigating and last visited etc..
3. Did everything perform as you expected it to? Yes
If no, what?
4. What would you change?
Not sure.
5. Did you think the system:a. Helped you navigate between sites - markedb. Made it harder to navigate between sitesc. Made it harder to view websitesd. Speeded up your searche. Slowed down your searchf. None of the above.
6. Why?It would have been more helpful on a larger search and may have speeded itup. Was definitely helpful in keeping track of sites which I wanted to visit, and saved having lots of windows open at once.
50
Questionnaire Results (3):
Post task questionnaire:1. What did you find hard to use?
Add one link to page got easily confused with add all links to page.Also had problems using the move link function. Wasn’t sure when an appropriate time to drop the link was.
2. What did you find easy to use?
Moving between web pages, Saving and re loading maps
3. Did everything perform as you expected it to? Yes
If no, what?
4. What would you change?
5. Did you think the system:a. Helped you navigate between sites - markedb. Made it harder to navigate between sitesc. Made it harder to view websitesd. Speeded up your searche. Slowed down your searchf. None of the above.
6. Why?
Didn’t lose the top end of my web browsing after going back and forth a few times.
51
Questionnaire Results (4):
Post task questionnaire:1. What did you find hard to use?
Found it hard to move links
2. What did you find easy to use?
Moving between links, was the same as web browser and so easy to use. Liked being able to view page screen shots, prevented me from going to the wrong page accidently.
3. Did everything perform as you expected it to? Yes
If no, what?
4. What would you change?
It would be nice if different subjects could be catalogued separately, as using for a long time could make the map become to confusing to use, and remember what is what.
5. Did you think the system:a. Helped you navigate between sites - markedb. Made it harder to navigate between sitesc. Made it harder to view websitesd. Speeded up your searche. Slowed down your searchf. None of the above.
6. Why?Gave clear list of previous sites visited which History doesn’t achieve, meaning could go back to sites which I may otherwise have forgotten about.
52
Appendix E
Source CodeA complete listing of all source code can be found on the attached floppy disk. A brief description of each file follows:
Html files:
The two html documents (add.html, addall.html) are used whenever an action on the browser context menu is fired. They both utilise java script to send the selected information to the browser in the form of a string appended to the url, which the system can then parse and utilise to add links to the map.
ContextMap.reg
This file is used to add the correct registry settings. Note that this file has only been tested on Windows XP home, and contains absolute path names, which are dependant on the path of the compiled system.
frmContainer.frm
This form is the main container, and holds most of the code for the user interface, this includes all code for animating movement on the map, as well as drawing the tree structure and sizing the scrollbars. It also contains code to handle all events, from both the browser and the menu system
frmMenu.frm
This form is simply a container to store the menus. It is declared in frmContainer and all events it raises are handled there.
modBand.mod
This code was obtained from Hamilton J. P. (2000) Visual Basic Shell Programming and used with permission by the author (as stated in the book). This module holds constants and references to the Internet Explorer object.
modHwndHandle.mod
This module is used to search for the window handle (as detailed in chapter 5). This is then used by modPic.mod.
modPic.mod
This code was originally sourced from www.vbcity.com however has had extensive changes made. The code takes the screen shot of the web page on view, and compressed it so it can be stored.
modSerialise.mod
This module holds functions for serialising and de-serialising the clsLink structure.
clsContainer.cls
As with modBand.mod this code was obtained from Hamilton J. P. (2000) Visual Basic Shell Programming and used with permission by the author (as stated in the book). It provides further implementation of the interface between Internet Explorer and the system.
53
clsLink.cls
This class module is the implementation of the tree structure. The root of the tree structure is an instance of this class, as are all of its children. This class contains all code for searching the tree and editing the tree, as well as returning all of the variables it stores.