Technical Working Paper

Transcription

1 Technical Working Paper This is a report on: The work to provide a handheld version of the Ericsson Leonardo Project Website. The work to produce a prototype mobile-learning course. Initial mobile-learning Management System implementation work.

2 1. Redesign of Project Site Technical Notes Development Tools Macromedia Dreamweaver MX Version Opera Technologies XHTML 1.0 Transitional CSS Levels 1 and Design 7 2. Prototype m-learning Course Development Tools Adobe Photoshop Technologies JavaScript DOM Design and Development m-learning Management System: Initial Stages WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp 36 2

3 1. Redesign of Project Site Technical Notes This section reports on technical details specific to the design of a lightweight alternative version of the original Leonardo Project Web-site (learning.ericsson.net/mlearning2/). Development work was undertaken to provide an alternative set of Project site pages suitable for browsing on handheld devices (Personal Digital Assistants and smart-phones) the goal was to produce small pages (i.e. pages that would fit on small screens), with images that would not cause excessive download delays. This section includes the following sub-sections: 1.1 Development Tools Macromedia Dreamweaver MX Version Opera Technologies XHTML 1.0 Transitional CSS (Cascading Style Sheets) Levels 1 and Design Development Tools Macromedia Dreamweaver MX Version 1.0 Macromedia Dreamweaver MX Version 1.0 was used during coding of the alternative Project site pages because it has the following features: A Site Definition Wizard that allows developers to specify a root folder where all site development work (sub-folders and files) is saved to. Once a site is defined Dreamweaver can automatically update all pages sharing a common template if 3

4 changes are made to the template. A site definition also provides developers with an efficient, mouse-click means of inserting pre-defined (in a CSS file) class and id names to HTML tags. A validator that can be set up to validate against a particular Markup language specification, e.g. XHTML 1.0 Transitional. A facility for previewing the page being coded in whichever installed browser has been specified for that purpose in Edit > Preferences > Preview in Browser Opera 7 Opera 7 was installed and used for previewing the alternative set of Project site pages. Although the support for such technologies as HTML, CSS and JavaScript provided by Opera 7 for Windows is greater than the reduced levels of support on handheld browsers (i.e. a handheld browser may not support as full a range of styling, design and dynamic page features), it has some validity as a previewing tool: Opera 6.31 was installed on the Project s Sony Ericsson P900 for browsing the alternative version of the original site after it had been uploaded to the Webserver. Despite its greater power, Opera 7 s page rendering characteristics would simulate Opera 6.31 s behaviour more closely than a different vendor s (e.g. Microsoft) desktop browser. When Show window size is flagged in Tools > Preferences > Windows, Opera 7 enables developers to precisely resize the page-viewing window to handheld device screen size by displaying width and height values in the title bar as the window s dimensions change. The address-bar of the Opera 7 page-viewing window can be toggled using Ctrl + F8, and its scrollbars can be toggled using Ctrl + F7. These features further aid developers wishing to get an impression of how optimized pages will look when viewed on a device screen. 4

5 1.2 Technologies The newest version of Opera s smart-phone Web-browser was installed on the Project P900. Opera 6.31 was chosen because it supports XHTML, a World Wide Web Consortium (W3C) technology developed with general user agent interoperability in mind. It was felt that XHTML should be used for the alternative Project site pages because it is a technology relevant to the next generation of mobile browsers. The latest advancements in wireless network capabilities make it possible to transfer greater amounts of data to handheld devices in much shorter amounts of time. More and more developers will opt for a Dynamic HTML (the combined power of HTML, Cascading Style Sheets, JavaScript and the Document Object Model (DOM)) approach over WML (Wireless Markup Language) to provide an interactive mobile browsing experience comparable to PC-based Web-surfing. The Opera 6.31 browser supports CSS Levels 1 and 2. Its support for JavaScript and DOM are discussed in section 2 of this technical working paper XHTML 1.0 Transitional To qualify as valid XHTML, each Web-page document of the alternative handheld site had to obey the following rules: 1. The document had to have an XML declaration: As the character encoding of the document was other than the default UTF-8 (Unicode Transformation Format-8), the document had to have an XML declaration. 2. There had to be a DOCTYPE declaration in the document, with the declaration referencing one of the three Document Type Definition (DTD) files for XHTML (strict, transitional or frameset): The DTD file for XHTML transitional was referenced. 3. The root element of the document had to be html, and the html element had to designate the XHTML namespace: An XML namespace is a collection of names, 5

6 identified by a URI reference, which are used in XML documents as element types and attribute names. 4. The document had to have the head, title, and body structural elements: A standard document should have the head, title, and body structural elements. 5. All elements in the document had to nest properly. 6. All element and attribute names had to be lowercase. 7. Every element had to have an end tag, unless declared in the DTD as EMPTY. 8. Empty elements had to have an end tag, or the start tag had to end with />: For example, <br> would not be valid; but <br></br> or <br /> would. The empty elements are: area, base, basefont, br, col, frame, hr, img, input, isindex, link, meta, and param. If /> syntax was used, there had to be a space before the /> (e.g. <br />). 9. Attributes could not be minimized: E.g., <td nowrap> would not be valid; but <td nowrap="nowrap"> would. 10. All attribute values had to be quoted. 11. Certain elements had to have an id attribute as well as a name attribute: These elements were: a, applet, form, frame, iframe, img, and map. 12. For attributes with values of an enumerated type, the values had to be lower case: E.g., align="center" would not be valid; but align="center" would. 13. All script and style elements had to have a type attribute. 14. All img and area elements had to have an alt attribute CSS Levels 1 and 2 CSS is a technology for attaching style (fonts, text-alignment, background-colors, element-positioning, and so on) to structured documents (e.g., HTML documents and XML applications). CSS enables authors to separate presentation style from document content, and this simplifies the Web-page development process. In addition, all style rules defining presentation and formatting throughout a Web-site are contained in a 6

7 single CSS file, and design refinements and changes that effect multiple pages are made in a single stop. The W3C released the first official version of CSS (CSS Level 1) in CSS1 provided a core set of capabilities for controlling presentation of content including the ability to set fonts, format text and set margins. CSS Level 2 was introduced in 1998 and provided developers with style sheet properties for content positioning, table-layout, internationalization (developing Web-pages that are easily adapted to specific local languages and cultures), and user-interface design. Level 2 also included all of the attributes of CSS1. A major benefit of CSS for the lightweight Project site was that it facilitated the implementation of well-structured, maintainable XHTML documents. As all presentation rules were centralized in an external.css file, the XHTML documents needed only to set out the basic structure of each Project site page, and therefore the mark-up s purpose and role would be clearly understood by anyone examining and maintaining the code in future. 1.3 Design This sub-section will describe the XHTML elements that provide the basic design of the alternative Project site pages, and the CSS rules used to control their appearance. As it was necessary to arrange the content of each page in a narrow vertical column (to avoid horizontal scrolling of pages on phone screens), a div generic container element, with its width set by the style sheet to 208 pixels (to suit the P900 s screen specifically), was used for all pages. The content on any of the pages would go between the start and end tags of this container, and would be constrained by the width settings of the container to produce a vertically stacked design. Table elements inside the div element were not automatically constrained by it and required their own CSS rules so that their widths remained less than 7

8 or equal to the column width. Fig1.3a shows the section of screen cordoned-off by the div element (represented by the rectangle outline) for all Project site page content. content. Fig1.3a The <div> element used to hold Project site page Fig1.3b shows the <table> element used to display the Ericsson logo, hold general links, and name the Project site page being displayed. 8

9 Fig1.3b The <table> element containing the Ericsson logo and general links, and naming the Project site page being displayed. As previously mentioned, the widths of table elements needed to be controlled with CSS, as setting a width for the div did not guarantee that all tables would remain as narrow as the container. As well as explicitly setting out widths (in pixels) for tables and table cells, a combination of two CSS2 property:value; pairs were used to exert still greater control over all table elements. These two CSS2 property:value; pairs are underlined in the code segment reproduced below: table { table-layout:fixed; border-collapse:collapse; } Setting the table-layout property to fixed would mean that table cell widths (and consequently table width) remained unaffected by the widths of content in cells. Setting border-collapse to collapse would collapse borders of adjacent table cells to ignore any padding or margins between adjacent borders. Fig1.3c illustrates the widening effect of padding or margins between adjacent cell borders, and Fig1.3d illustrates how a bordercollapse setting of collapse collapses the adjacent borders and makes overall table width easier to predict. Fig1.3c When there is padding or margins between adjacent cell borders (represented by the black lines), predicting final table width becomes more difficult. 9

10 Fig1.3d A border-collapse setting of collapse collapses the adjacent borders of table cells and makes overall table width easier to predict. One further CSS property was set (for table cells) so that only cell widths (the widths of the grey areas in Fig1.3c and Fig1.3d) and border widths (represented in diagrams by black lines) would need to be added in calculating final table width. Cell-padding (represented as white surrounding the grey space in cells in previous diagrams) was removed from all table cells by setting padding:0px; for each cell. With border-collapse set to collapse, and padding set to 0px for each cell, the horizontal space a table occupied across the screen was dependent only on cell widths (the widths of the grey areas in diagrams) and the widths of any borders between cells (this concept is conveyed in Fig1.3e). Fig1.3f conveys the notion of simplified final table width calculation (facilitated by CSS settings that eliminate widths of content in cells, padding or margins between adjacent borders and cell-padding as considerations). Fig1.3e With border-collapse set to collapse, and padding set to 0px for each cell, the horizontal space a table occupied across the screen depended only on cell widths and the widths of any borders between cells. Fig1.3f Only cell widths (grey areas) and borders (black lines) needed to be included in calculations to determine whether final table width would remain less than or equal to the width of the <div> container. With the measures outlined so far, CSS provided the level of control needed to ensure all Project site page content remained within the width of the div container. Fig1.3g shows 10

11 (with thick rectangle outlines) the tables that are present in the basic alternative Project site page design. Project site page design. Fig1.3g The tables that are present in the basic alternative The second table from the top of the page in Fig1.3g was actually put inside a <div> container of equal width and height (i.e. the second table exactly filled its small column container). Therefore, in terms of a graphic representation of this particular <div> element, the thick rectangle border used for the second table in Fig1.3g also serves as an exact marker for the container holding that table. Two <div> containers were in fact floated (containers can be used to create side-by-side column layouts by floating them inturn along the same horizontal band) against one-another below the first table for every 11

12 page. The CSS1 float property was set to left (float:left;) for both div elements so that they would rest against one-another along the bottom of the first table with the first <div> s edge aligned exactly with the edge of the overall container. Fig1.3h and Fig1.3i show two ways in which the pair of floated <div> containers could be used in the layout of a page. (Note: As the floated containers were placed inside an overall container with a specified width of 208 pixels, they would not split apart if a particular smart-phone s browser window was less than 208 pixels wide). Fig1.3h The floated <div> containers side-by-side below the first table. (The overall container is also shown). 12

13 Fig1.3i The floated <div> containers of the Project: Docs page side-by-side below the first table. (The overall container is also shown). In the area of the screen below the floated containers a table or <div> could be used to hold some other page content. Fig1.3j shows the <table> that was placed below the floated <div> elements of the Project: Partners page. Fig1.3k shows the <div> used (below the floated <div> elements) to display some of the content of the Project: Home page. 13

14 Fig1.3j The <table> (below the floated <div> elements) used to display some of the content of the Project: Partners page. 14

15 Fig1.3k The <div> (below the floated <div> elements) used to display some of the content of the Project: Home page. 15

16 2. Prototype m-learning Course A WCDMA / UMTS Radio Access Network Overview course was developed for smart-phone users using a succession of linked XHTML Web-pages that load into a frame element in a user-interface page. The development tools (Macromedia Dreamweaver MX Version 1.0 and Opera 7) and technologies (XHTML 1.0 Transitional and CSS Level 2) used to provide the lightweight alternative version of the Project Web-site were also important in this project. In addition, an image-making tool (Adobe Photoshop 5.5) was used to design and create small diagrams for course pages, and JavaScript and DOM technology facilitated the provision of dynamic page features. Only those development tool and technology issues not already addressed in section 1 will be discussed in this section. 2.1 Development Tools Adobe Photoshop 5.5 Photoshop provides settings when an image is being saved in Graphics Interchange Format (GIF) that enables the developer to produce a lightweight graphic for improved Web-page download time: Transparent areas from the original Photoshop image can be included in the GIF Web version (to produce a GIF with a transparent background). As well as preserving the full transparency of background pixels, the developer can use a matting feature to ensure that pixels at the edge of an anti-aliased shape blend with the Web-page s background-colour. A Web color palette can be specified for the image (to use the palette most often used by Web browsers). 16

17 Fig2.1.1a and Fig2.1.1b are examples of prototype course pages that include GIF diagrams. Fig2.1.1a This is an example of a prototype course page that includes small, transparent-background GIF diagrams. 17

18 Fig2.1.1b This is an example of a prototype course page that includes a small, transparent-background GIF diagram. 18

19 2.2 Technologies JavaScript JavaScript is a scripting language for creating simple code to control the behaviour of Web-document objects. Web-page elements such as tables, table cells, images, <span> elements and <div> containers are accessible through corresponding object representations in the DOM. In the discussion on the design and development of the prototype m-learning course, the way in which JavaScript functions toggle the visibility of course user-interface icons and headings will be discussed further. In response to user clicks, these functions use the DOM to control objects representing <img> and <span> elements so that particular icons and headings are shown or hidden. The JavaScript functions that control the dynamic user-interface of the prototype course are triggered by user interaction with clickable page elements. After an event (such as a mouse-click on an anchor, or the loading of the body section of the document) occurs, the browser checks whether there is JavaScript code to be called. The browser will carry out the instructions in the JavaScript function that is supposed to be called when that particular event occurs. Fig2.2.1a shows how different icons (open-folder or closed-folder icons) and headings appear on the navigation panel of the course when the user goes from one lesson to another after clicking a lesson number (outlined). 19

20 Fig2.2.1a The navigation panel of the prototype course displaying different icons and headings after the user goes from one lesson to another. Basically, the <img> and <span> element objects available to JavaScript through the DOM provide access to the style sheet visibility property settings for the elements. (JavaScript also changes the background-color settings for certain table cell elements when the user makes lesson-section selections (this functionality is not shown in Fig2.2.1a)). JavaScript code is included in Web-page documents by placing it between opening and closing <script> tags. JavaScript is used to write scripts that run client-side on the Web-browser. This contrasts with a situation where code instructions in a Web-page document run on the Web-server before the page is sent to the client. A JavaServer Page (JSP) is a type of Web-page file that includes scriptlet code that is compiled and run on the Web-server. This server-side technology is discussed in section 3 of this document. JavaScript began life as a Netscape scripting language but as it grew in popularity the other leading browsers (Internet Explorer, Opera, Mozilla and Safari) provided support for it or ECMA script (a closely related European Computer Manufacturers Association standardised specification). 20

21 2.2.2 DOM The ability to change the appearance of a Web-page dynamically with JavaScript is made possible by the DOM. The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. The W3C DOM is designed to be a standard, cross-browser Application Programming Interface (API) to the structure of documents. The DOM allows scripts to access a Web-page through a hierarchical structure with the window itself at the beginning, and breaking down into nodes and child nodes. A <div> container element with an <img> child element, for example, would form a parent element node to child element node link in the abstract view. The DOM can connect any element on a page to a JavaScript function. To find, for example, an <img> element in the document with an id attribute value of diagram1, the following path is used in JavaScript: window.document.images.diagram1 An easy way to access an object in a document is to pass the unique name value of the element s id attribute to the getelementbyid method of the Document interface: document.getelementbyid( diagram1 ) JavaScript functions in prototype course pages use the getelementbyid approach when changing particular elements style sheet property settings. The following code segment was used so that a particular group of section-headings would appear on the navigation panel whenever a user chose the corresponding lesson: 21

22 while (startheadingnonewgroup < startnonextgroup) { document.getelementbyid('topic_sect_heading' +startheadingnonewgroup).style.visibility = 'visible'; startheadingnonewgroup++; } Each of the elements in the group targeted in the previous code segment is uniquely identified by a number part in its id attribute value, e.g. topic_sect_heading17. This is why concatenation with a startheadingnonewgroup variable is necessary in each iteration of the loop. Fig2.2.2a shows the section-headings group ( Section Objectives, Spectrum and Duplex Tech. s, and Multiple Access Technologies ) that appears when the user clicks Lesson 3. Fig2.2.2a The section-headings group (bracketed) that appears when the user clicks Lesson 3. The W3C did not standardise the DOM until recently, and older browsers (Netscape 4 and Internet Explorer 4) implemented their own conflicting DOMs. However, the majority of modern browsers now support the W3C DOM. During development of the prototype course, it was discovered that the Opera 6.31 browser does not have a complete W3C DOM implementation. During testing JavaScript code to change the background style sheet property setting worked on Opera 7, but not on Opera The differences between the Opera 7 and Opera 6.31 DOM implementations highlighted an important consideration JavaScript in pages produced for smart-phones / PDAs cannot be guaranteed the level of control over document objects that a full DOM implementation would provide. For the prototype course, JavaScript use of the DOM was 22

23 simplified and a getelementbyid approach was settled on for dynamically changing certain elements background-color or visibility style sheet property settings. 2.3 Design and Development The prototype course user-interface screen (a Web-page with an iframe element for loading course material) was created with a column <div> container that holds all content. Fig2.3a highlights this container. (Please see overleaf) 23

24 Fig2.3a The <div> containing all other elements of the prototype course user-interface page. The <div> container holds a table element (used to create a navigation panel ), and the course material iframe. The table element is highlighted in Fig2.3b, and the iframe is highlighted in Fig2.3c. 24

25 Fig2.3b The navigation panel in the course user-interface page. 25

26 course user-interface screen. Fig2.3c The iframe used for loading course material into the The user-interface page was designed to behave dynamically. When the user clicks a lesson number on the navigation panel, the icons and headings displayed by the panel change, and new material is loaded into the <iframe> element. Fig2.3d illustrates this dynamic capability. 26

27 Fig2.3d Example dynamic changes (changed navigation panel folder icons and headings, and changed course material) on the user-interface. JavaScript included in the user-interface page provides the dynamic features shown in Fig2.3d. The folder icons are <img> elements, and each heading that JavaScript needs to control is placed in a separate <span> element. JavaScript functions in the user-interface page respond to user interaction by changing style sheet visibility property settings for different combinations of <img> and <span> elements. If the visibility property 27

28 setting for an element is hidden then it cannot be seen on-screen, while it is shown when its visibility property is set to visible. There are a number of set locations on the navigation panel for displaying dynamically updating icons or headings. These locations are highlighted in a close-up view of the navigation panel in Fig2.3e. panel where folder icons or headings are displayed. Fig2.3e The locations on the navigation At any time there will be one specific icon (either an open-folder or closed-folder icon) or heading displayed at each location. Fig2.3f shows the navigation panel display for Lesson 2. Lesson 2. Fig2.3f The navigation panel display for 28

29 Fig2.3g shows the navigation panel display for Lesson 4. Lesson 4. Fig2.3g The navigation panel display for All of the icons (either an open-folder or closed-folder icon) or headings needed for a specific location are stacked on separate virtual layers above that location. The elements are placed on separate layers by setting the style sheet position property to absolute for each element. The separate layers created in this way act like transparent sheets stacked on top of one another. It would be possible to create a vertical stack of icons or headings using transparent sheets placed over one another if each sheet had a different icon or heading text. CSS was used to achieve virtual layering of elements over the course user-interface and each dynamic display location on the navigation panel has its own icon or headings set stacked above it. Fig2.3h conveys this concept. Fig2.3h The dynamic display locations of the navigation panel, each with a set of icons or headings stacked above it. 29

30 To provide a different displayed combination of icons and headings for each lesson in the course, the JavaScript in the user-interface page allows only one element from each stacked set to be visible at any time. This is why, when the user chooses a particular Lesson no., one specific, corresponding icon (either an open-folder or closed-folder icon) or heading is displayed at each of the dynamic display locations highlighted in previous screen-shots. The JavaScript dynamically updating the navigation panel ensures that only one element from each stack set has its style sheet visibility property set to visible. Fig2.3i shows which icon or heading from each stacked set is visible for Lesson 2 (the way in which the navigation panel appears on-screen to the user is shown on the right). The icon or heading from each stacked set that is visible for Lesson 2. Fig2.3i Fig2.3j shows which icon or heading from each stacked set is visible for Lesson 4 (the way in which the navigation panel appears on-screen to the user is shown on the right). The icon or heading from each stacked set that is visible for Lesson 4. Fig2.3j The dynamic behaviour of the course user-interface was achieved by combining the power of CSS, JavaScript, the DOM and XHTML. This combination of technologies is 30

31 referred to as Dynamic HTML (DHTML), and it is an approach that can be taken for the latest smart-phone / PDA browsers connecting to 3G (3 rd generation) networks. JavaScript updating of the user-interface display when the user chooses a Lesson no. also involves loading corresponding material into the page s iframe. It is a separate Web-page (displaying material that corresponds with the Lesson no. chosen) that is loaded into the iframe. The following code is used to load different pages into the iframe in the userinterface page: frames['iframe_wcdma_ran_overview'].location.href = 'lesson'+currentlessonno+'_sect'+bartoactivate+'.html'; Fig2.3k shows some of the pages that can be loaded into the user-interface <iframe>. 31

32 Some of the pages that can be loaded into the user-interface <iframe>. Fig2.3k In relation to the design of the course material pages that load into the interface <iframe>, the major challenge was how to convey ideas diagrammatically in the limited space available. Concise, uncluttered diagrams were the aim. Diagram key color codes were used to avoid having to insert explanatory or labelling text directly into graphics. Sometimes the complexity and size of a necessary diagram could not be reduced enough for device screen size. A scaled-down, simplified image map version with different 32

33 clickable areas was used to provide links to separate full-size sub-section views of the original graphic. Fig2.3l, Fig2.3m and Fig2.3n convey a sense of how one particular scaled-down, simplified image map graphic is used to load separate sub-section views of a complex, large original diagram. Fig2.3l The first (left-hand-side) section of a scaled-down image map graphic is clicked to load a sub-section view of the large, original diagram. 33

34 Fig2.3m The second (middle) section of a scaled-down image map graphic is clicked to load a sub-section view of the large, original diagram. Fig2.3n The third (right-hand-side) section of a scaled-down image map graphic is clicked to load a sub-section view of the large, original diagram. Fig2.3o shows the course page that the clickable image map graphic of the previous screen-shots appears on. This course page is shown loaded into the user-interface page s <iframe>. 34

35 Fig2.3o The course page that the clickable image map graphic of the previous screen-shots appears on. This course page is shown loaded into the user-interface page s <iframe> (outlined). 35

36 3. m-learning Management System: Initial Stages This section will discuss the initial stages of work to provide m-learning Management System functionality for the prototype course discussed in section 2. The mlms, it was decided, should provide login, registration, work-plan submission, student progress tracking and administration features for mobile device users. This development work began with the implementation of test login and registration JSP pages that connect to a database backend on the Web-server to verify registrationid and password details, or store new user information. This section will concentrate on the test login JSP page to show how JavaServer Pages technology can be used to provide server-side processing of user data. The basic operation of the test registration JSP page is the same as that of the test login JSP page. 3.1 WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp As has been explained in Section 2.2.1, JavaScript code that is embedded in a Webdocument is downloaded by the handheld device and executes on the device (after, for example, the user clicks on a particular area of the downloaded Web-page). JSP code is also embedded in Web-page documents, but is executed on the server before the page is sent to the device. These small programs specified in the Web-page (the Web-page document is saved with a.jsp file extension) run on the Web-server to modify the Web-page before it is sent to the user who requested it. The Java 2 SDK, Enterprise Edition v1.3.1 provided a Web-server for the Project P900 to connect to during early mlms development work. The code in the test login JSP, WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp, validates registrationid and password details on the server to decide which message ( Invalid registrationid, Invalid password etc.) to add to the page before it is sent to the device. This is a summary of how the login JSP page works: 36

37 The handheld device browser sends the registrationid and password details entered by the user on the device to the J2EE SDK Web-server with the request for WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp. JSP code in the WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp page runs on the Web-server, checking whether the registrationid and password details submitted match database stored information. The JSP code in WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp is needed to ensure that a particular course of action is taken based on database search results. If the small program does not find matching information in the database an unsuccessful login message is added to the rest of the.jsp file s Webpage content. Then, when the JSP page has finished running on the Web-server, it is sent to the handheld device browser displaying a failed login message. If matching registrationid and password information is found in the database, the JSP page prevents itself from being sent to the device browser by instructing the Web-server to supply a successful login user home-page instead. A JSP page includes program instructions that run on the Web-server to make changes to the page before it is sent to a requesting Web-browser. The code in WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp is needed to ensure that a particular login status message ("Invalid registrationid" or "Invalid password") is added before the page goes to the browser. The page is designed so that a browser can include registrationid and password details with the request for the page, and then a specific login status message is dynamically added before the page is sent to the browser. The WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp page acts as a login status feedback page in this way. Sometimes the small server-side program included in WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp does not add a message to the page. WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp tells the Webserver to send a user home-page to the browser in its place if a login details match is found in the database. 37

38 Fig3.1a shows what the WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp page looks like when an unsuccessful login attempt is made and it has been sent to the handheld device browser displaying a login failure message (the mlms will be accessible from the lightweight alternative Leonardo Project Web-site, and its screens will be designed to compliment the site-look ). (Please see overleaf) 38

39 Fig3.1a WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp when an unsuccessful login attempt is made and it has been sent to the handheld device browser displaying a login failure message. The page that WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp instructs the Web-server to send in its place when a successful login is made is shown in Fig3.1b. 39

40 Fig3.1b The page that WCDMA_UMTS_Radio_Access_Network_Overview_Login.jsp instructs the Web-server to send in its place when a successful login is made. 40

41 41

42 42

43 43