ĐĎॹá>ţ˙ žŔţ˙˙˙ź˝˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ěĽÁq` đż2ŽbjbjqPqP .Â::2†˙˙˙˙˙˙¤¤¤¤¤¤¤¤¸@t@t@t@tTt´¸ú~śuuuuuuuuy~{~{~{~{~{~{~$°h‚tŸ~¤ŻvuuŻvŻvŸ~¤¤uu´~~~~Żvb¤u¤uy~~Żvy~~~¤¤~uu  ÷ŢšÂ/Ě@t|˛~y~Ę~0ú~~Œ‚Ă|HŒ‚~Œ‚¤~duL`u6~–u,ÂuíuuuŸ~Ÿ~ ~ uuuú~ŻvŻvŻvŻv¸¸¸¤M\Qä"¸¸¸\Q¸¸¸¤¤¤¤¤¤˙˙˙˙ 1 Welcome! This course will take you through the steps for developing dotMobi sites. First we’ll talk about the mandatory rules. Then we’ll go through creating an XHTML Mobile Profile page and testing it in a browser. We’ll then discuss copying the files to a web server, using the dotMobi validator, and how to test files in an emulator. We’ll also show you where to download the dotMobi templates, take a look at a few sample sites, and discuss best practices. And we’ll mention some additional tools including Dreamweaver, the Firefox User Agent Switcher, and Google’s Mobile Web Search. Lastly, we’ll show you how to access the dotMobi developer site, a great resource for both beginning and advanced dotMobi developers. Let’s get started! 2 The goal of three dotMobi Mandatory Registrant Rules described in the following three slides, is to ensure a good user experience for users interacting with sites on the dotMobi domain. You’ll want to make sure that your site is in compliance with the mandatory rules. Any sites out of compliance will eventually have their dotMobi domain name placed on hold, which will prevent the site from being viewed, until the site is brought into compliance. Let’s go through the three mandatory rules. They’re not difficult. 3 The standard markup language for dotMobi pages is XHTML Mobile Profile. You are required to use XTHML Mobile Profile markup language for the home page of your site if your web application does not have the means to distinguish between devices, or, if your web application is able to distinguish between devices but does not recognize the current device. So, unless you have a sophisticated application that detects the type of device making the page request and adapts dynamically to the device’s capabilities, you need to be creating your mobile pages in the XHTML Mobile Profile format. In a couple slides from here, we’ll be explaining, in detail, how to write pages in the XHTML Mobile Profile format. 4 The second mandatory rule is that your web server needs to support the user typing in the domain name to your site without requiring them to type www. Pointing the second-level domain (e.g. domain.mobi) at the same site as the third-level domain (e.g. www.domain.mobi) makes it easier for users to get to your site. Research has shown that typing in URLs on a mobile phone is a significant barrier to entry for users using mobile devices. 5 The third, and last, of the mandatory rules is that you should generally not be using frames. Now that we’ve taken a look at the mandatory rules, let’s go through the process of creating an XHTML Mobile Profile page for your dotMobi site. 6 You can write your XHTML Mobile Profile code in any text editor, including Notepad TextPad, or ConTEXT. When you save your file, you will need to specify the .xhtml extension. 7 The first two lines of code will be the same for all of your XHTML Mobile Profile files. The first line of code at the beginning of the file will be the XML declaration, which states that this is an XML file. The second line of code states the document type in detail. The document type needs to be XHTML Mobile 1.0, as shown. 8 The remaining code in the file needs to be in the XHTML format, which means it’s XML compliant (aka “well-formed”) and only uses HTML tags. Rules of XHTML include case-sensitivity, all tags must close, all attributes must have values, and all values must be in quotes. 9 Case-sensitive. Most developers write their XHTML code in lower-case. Either way, the opening and closing tags must match exactly. All tags must close, either by having a separate closing tag or by including a trailing slash toward the end of the opening tag. All attributes must have values. And all values must be in quotes. 10 Once you’ve created your .xhtml file and saved it to your computer, the next step is to open the file in a browser so that you can see how the page looks and make sure there aren’t any errors in your XHTML markup. If you find any errors in your code, you’ll want to go back to your code editor, make the changes, save the file, and then reload the file in your browser. 11 To help with testing your XHTML markup in a browser, there is an excellent HTML Validator extension available for Firefox that allows for checking XHTML markup. If you go to download and install the extension, choose the SGML option. It’s best for checking XHTML. 12 Once you’ve installed the extension, open your page in Firefox, and, looking in the lower right-hand corner, notice either a green checkmark, which means you have no errors in your XHTML code, or a red X, which means you do have errors in your XHTML code. If you go ahead and roll over the green checkmark or red X, you’ll see a pop-up message that tells you how many errors there are in your XHTML code. 13 If you do have errors, you’ll want to double-click on the red X. That’ll bring up a window that gives you a detailed list of the errors in your XHTML code. If you find any errors in your code, you’ll want to go back to your code editor, make the changes, save the file, reload the file in your browser, and make sure that you eventually get the green checkmark. Once you get the green checkmark for all of your files, the next step is to copy the files to your dotMobi web server. 14 A dotMobi web server is a web server that has a .mobi domain (e.g. dev.mobi) pointing to it If you haven’t yet registered a dotMobi domain name, you can contact a dotMobi registrar in order to purchase one. Once you’ve got your dotMobi web server set up, you’ll want to copy your .xhtml files over to it 15 To copy your .xhtml files to your dotMobi web server, go ahead and copy them using whatever method you normally use for copying files to a web server, whether it be FTP, RDS, SourceSafe, copying the files across your network, or any other method that you’re comfortable with. 16 Once the .xhtml pages coming from your server are showing up correctly in your browser, the next step will be to test the pages using the dotMobi validator. To help you get started, dotMobi offers template files, free to download and use. There are two template versions, corresponding to two sizes of devices in common usage. The small, or narrow, version of the template best fits lower end devices, whereas the larger, or wider, one best fits smartphones and PDAs. You should pick the one that best suits your expected audience. In general, the narrower one is the safer choice. You can set up a web server to use both, where it dynamically returns pages depending on the requesting browser. Look on the dotMobi developer site for an article on this coming soon. 17 If you have issues when testing the URLs coming from your web server, and you think the web server may not be sending the document content type to the browser, then you’ll want to check that the XHTML MIME type is set up on the server. How you go about setting up the MIME type depends on the web server you’re using. Pictured here is a screenshot from Microsoft IIS. Clicking on the blue link shown will take you a web page that describes setting up MIME types for most web servers. Once the .xhtml pages coming from your server are showing up correctly in your browser, the next step will be to test the pages using the dotMobi validator. 18 The dotMobi validator, located at http://validator.mtld.mobi, allows you to check your pages for compliance with the dotMobi mandatory style guide rules, as specified in the dotMobi Switch On! Web Developer’s Guide mentioned on slide 3. If you have any errors, you’ll need to go back to your code, fix the errors, re-save your files, re-test the files in your browser, re-copy the files to your web server, re-test them in your browser from the web server, and then re-validate them in the dotMobi validator. If you receive errors when validating your pages and you do not fix your files to comply with the dotMobi mandatory style guide rules, your dotMobi domain will eventually be put on hold which will prevent it’s resolution on the Internet, until the site is fixed to be in compliance with the mandatory rules. After using the dotMobi validator to confirm that your files are in compliance with the mandatory rules, the next step is to view your pages in an emulator. 19 Emulators are used to simulate devices, providing a quick way to test pages without having to type URLs into an actual phone or other wireless device. Openwave, an early innovator in the mobile environment, offers the Openwave Phone Simulator, free of charge. Nokia, as well, offers the Nokia Mobile Browser Simulator, free to download and use. While emulators can’t truly replace testing your pages in the actual mobile devices your users may be viewing your pages in, they can be very useful for speeding up your development time. 20 To test a page from your dotMobi web server in your emulator, simply type the URL into the emulator’s address area. To test a page located on your computer in your emulator, Choose Open File from the File menu. Most emulators do a fairly good job of reproducing the mobile device, including the navigation controls. 21 After successfully testing your pages in an emulator, you will, however, still need to test the pages in the actual mobile devices that you think your end-users may own, because each device is a little different. You’ll want to ensure that the experience your users are receiving on each of their devices is how you intended your site to look and perform. Now that you’ve seen the overall process for creating .mobi pages, on the following slides we’d like to provide you with some additional tools and information to help you get started and be successful. 22 To help you get started, dotMobi offers template files, free to download and use. There are two template versions, corresponding to two sizes of devices in common usage. The small, or narrow, version of the template best fits lower end devices, whereas the larger, or wider, one best fits smartphones and PDAs. You should pick the one that best suits your expected audience. In general, the narrower one is the safer choice. You can set up a web server to use both, where it dynamically returns pages depending on the requesting browser. Look on the dotMobi developer site for an article on this coming soon. 23 The template files are fully compliant with the dotMobi mandatory style guide rules. Once you’ve downloaded the template files, simply replace the content with your company’s information and graphics. The templates are totally customizable, and contain extensive comments. Then, as with any pages you create, be sure to test them in the dotMobi validator to make sure the results of your changes are in compliance with the dotMobi rules. 24 To give you some ideas of how others are developing sites for the dotMobi domain, we’ll take a look at three examples over the next three slides. These sites, plus more, can be accessed at http://demo.mtld.mobi. To see the code that makes up any of the pages in any these sites, you can simply browse to the page on your computer, and then choose View – Page Source. That’ll allow you to see the XHTML code for the page, and thereby understand how the page is constructed. 25 This dotMobi site is for the 2006 GSM Awards, the leading international awards program honoring excellence throughout the global GSM mobile industry. The .xhtml file is shown on the left. Next to it is what the page looks like in a regular browser. On the right is what the page looks like in an emulator. The URL to access this dotMobi page is http://gsmawards.mobi/content.xhtml. 26 This is the home page for BMW’s English dotMobi site. On the left is the code in the .xhtml file, in the middle is how the page looks in a regular browser, and on the right is how the page looks in an emulator. 27 This is the home page for Google’s dotMobi site. On the left is the code in the .xhtml file, in the middle is how the page looks in a regular browser, and on the right is how the page looks in an emulator. 28 As you create your dotMobi site, we’d like to you be aware of a number of dotMobi and W3C best practices. Best practices are not required, but are highly recommended, in order to ensure users have a good experience accessing your dotMobi site. For each W3C best practice in the following ten slides, you can click the link for further discussion of the meaning of the statement. 29 Best practices: overall behavior Ensure that content provided by accessing a URI yields a thematically consistent experience when accessed from different devices. Site at example.com should be “about” the same thing whether accessed by a mobile device or a PC. For example, if site at weather.com delivers weather forecasts when accessed by a PC, then it should also deliver weather forecasts when accessed by mobile devices. Exploit device capabilities. Do not take a least common denominator approach. If you know a device to support a particular capability which could improve the user experience, then you should make use of this where possible, instead of taking least common denominator approach (whereby you offer a minimal experience which works on all devices) . Take reasonable steps to work around deficient implementations. Some things don’t render correctly on some devices – where you are aware of such issues, try to avoid them, possibly even at the cost of violating other best practices. Carry out testing on actual devices as well as emulators. Perform tests on real devices – emulators aren’t always accurate. 30 Best practices: navigation and links Keep the URIs of site entry points short. Keep addresses short – its hard to type on a phone. Hence http://example.org is better than http://www.example.org/index.html and example.org/example is better than www.example.org/example.html. Provide only minimal navigation at the top of the page. Provide only basic navigation at top of page. Users should be able to see page content immediately when the page loads, without having to scroll down. For example place links on one line at top of page. Secondary navigation links should be place at the bottom of the page. Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for. Scrolling a page when there are many links on it can be very cumbersome, as the scrolling action on many mobile devices selects each link in turn. On the other hand, each retrieval of a navigation page takes time and adds cost, so the number of links on a page should not be minimized at the expense of adding page retrievals. Try to provide a balance between having a lot of navigation links on a page and the need to follow multiple links to reach content. Provide consistent navigation mechanisms. Using the same navigation mechanisms across a service enables users to navigate more easily. A "drill-down" method, based on major headings, can often provide an effective means of navigation; because of the linearized arrangement of content, small screen size and lack of pointing device, it is often useful to provide a means to jump entire sections of content. At each target of the drill-down navigation an "up" link should be provided to allow the user to jump up an entire section. Assign access keys to links in navigational menus and frequently accessed functionality. Where there is no pointing device, assigning an access key (keyboard short cut) to a link can provide a convenient way for users to access the link and avoid navigating to the link by repeated pressing of the navigation key. Provide the same access key for links that are repeated across pages such as links to the home page. Clearly identify the target of each link. 31 Note the target file's format unless you know the device supports it. Mobile users may incur undue costs and delay by following links. Use clear, concise, descriptive link text to help users decide whether to follow a link. Identify the size of the link target (e.g. in bytes) and the type of target file (e.g. pdf) as users may not wish to download files they cannot view. All formats other than XHTML, GIF and JPG should be noted. Do not use image maps unless you know the target client supports them effectively. Many mobile devices lack a pointing device and server-side image maps cannot be used on such devices. Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. Do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it. Do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes. Each of these activities is likely to cause the user confusion, or add cost and delay to their interaction. Some mobile devices use a separate window for input; this section does not refer to such windows. Many mobile devices cannot support more than one window and consequently, attempting to open one will have unpredictable results. Auto-refreshing pages are widely recognized as presenting accessibility problems. In a mobile environment they may expose the user to undue cost as a result of such a page being left open or put unnoticed into the background. If an auto-refreshing page is demanded by the application, always provide a means of ceasing the refresh and always inform the user that the page will refresh and may expose them to higher usage costs. While redirection is a commonly employed mechanism, it must be remembered that redirection usually requires a round-trip to the browser. This adds to delay on slow links; so use a maximum of one redirect per page and limit the number of pages that are redirected. Keep the number of externally linked resources to a minimum. Since each external resource requires a separate request across the network significant load time may be added to a page. Number of images should be minimised and style information should be included in one sheet per page. 32 Best practices: page layout and content Ensure that content is suitable for use in a mobile context. Use clear and simple language. Limit content to what the user has requested. Mobile users are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information and, while providing the option to access all information, should offer appropriate information first. Divide pages into usable but limited size portions. Ensure that the overall size of page is appropriate to the memory limitations of the device. If pages are too big they may take an unduly long time to load. In addition, mobile devices typically have restrictions on the largest page they can accommodate. On the other hand, if pages are too short then the user will be required to make multiple requests to read the relevant information. This can lead to an unnecessary delay. Limit scrolling to one direction, unless secondary scrolling cannot be avoided. If some element on the page requires secondary scrolling it must not cause the remainder of the page to require this. For example, if an object causes subsequent text to lay out with a significant margin to its left, then this text may not be visible once a user has scrolled past the object. Equally, if the presence of such an object causes text to render beyond the right boundary of the page then the user will be required to scroll to read each line of text. 33 Ensure that material that is central to the meaning of the page precedes material that is not. Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page. The user should not have to scroll significantly to find the primary content of the page. Do not use graphics for spacing. Do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost. Ensure that information conveyed with color is also available without color. Ensure that foreground and background color combinations provide sufficient contrast. When using background images make sure that content remains readable on the device. 34 Best practices: page definition Provide a short but descriptive page title. Use a short title to help identify the content, bearing in mind that it may not be displayed in some devices. Some devices also use this as a label for bookmarks, so no title could mean a blank bookmark name. Use features of the markup language to indicate logical document structure. Use headings and subheadings to indicate document structure – this is better than using arbitrary formatting. Do not use tables unless the client is known to support them. Do not use nested tables. Do not use tables for layout. Where possible, use an alternative to tabular presentation. Tables don’t work well on small screens and may result in the user having to scroll horizontally to see important content. 35 Provide a text equivalent for every non-text element. Do not rely on embedded objects or script. Downloading images to a mobile client adds to the time to display an image and the cost of displaying the page. Making the page readable in text-only mode can help the user assess its usefulness before images arrive. Specify the size of images in markup, if they have an intrinsic size. Resize images at the server, if they have an intrinsic size. Telling the browser in advance what size the images are avoids it having to re-flow the page after images load – and reduces the amount of work the browser needs to do to scale the image. Create documents that validate to published formal grammars. Invalid markup may display unpredictable or not at all. Valid markup will render more quickly and correctly. Do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values. Using percentage and relative measures such as em, ex, bolder, larger and thick, over pixel measures allows the browser to adapt content to fit the display. (An exception to this is the case where image sizes are specified in terms of pixels). 36 Use style sheets to control layout and presentation, unless the device is known not to support them. Organize documents so that they may be read without style sheets. Keep style sheets small. Mobile Devices offer varying support for style sheets. Some provide full implementations, including caching of external style sheets; some do not cache external style sheets; some do not support the style element; some implementations do not support more than one style sheet and some do not support style sheets at all. It is preferable to share style information between pages, but if the device does not support caching of style sheets then this approach would result in the same style sheet being retrieved for each page. Consequently, in order of preference: if the device caches style sheets, put style information in a single external style sheet; if the device supports the style element, use it; otherwise use an external style sheet. Only styles that are used should be included. Use terse, efficient markup. Removal of redundant white space and new-lines can reduce markup payload size. Marking fonts, colors and other stylistic effects in-line can cause considerably larger page sizes when compared with using logical markup, and use of the HTML class attribute for application of style. Send content in a format that is known to be supported by the device. Where possible, send content in a preferred format. To determine what formats a device supports, Web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers, UAProf or WURFL. 37 Best practices: page definition Provide a short but descriptive page title. Use a short title to help identify the content, bearing in mind that it may not be displayed in some devices. Some devices also use this as a label for bookmarks, so no title could mean a blank bookmark name. Use features of the markup language to indicate logical document structure. Use headings and subheadings to indicate document structure – this is better than using arbitrary formatting. Do not use tables unless the client is known to support them. Do not use nested tables. Do not use tables for layout. Where possible, use an alternative to tabular presentation. Tables don’t work well on small screens and may result in the user having to scroll horizontally to see important content. 38 Use style sheets to control layout and presentation, unless the device is known not to support them. Organize documents so that they may be read without style sheets. Keep style sheets small. Mobile Devices offer varying support for style sheets. Some provide full implementations, including caching of external style sheets; some do not cache external style sheets; some do not support the style element; some implementations do not support more than one style sheet and some do not support style sheets at all. It is preferable to share style information between pages, but if the device does not support caching of style sheets then this approach would result in the same style sheet being retrieved for each page. Consequently, in order of preference: if the device caches style sheets, put style information in a single external style sheet; if the device supports the style element, use it; otherwise use an external style sheet. Only styles that are used should be included. Use terse, efficient markup. Removal of redundant white space and new-lines can reduce markup payload size. Marking fonts, colors and other stylistic effects in-line can cause considerably larger page sizes when compared with using logical markup, and use of the HTML class attribute for application of style. Send content in a format that is known to be supported by the device. Where possible, send content in a preferred format. To determine what formats a device supports, Web sites may use any combination of device profile information such as the HTTP User-Agent header, HTTP Accept headers, UAProf or WURFL. 39 Ensure that content is encoded using a character encoding that is known to be supported by the target device. Indicate in the response the character encoding being used. The supported character encodings for a device may be obtained either from a device profile or by examining the value of the HTTP Accept-Charset header. The character encoding being used in a response may be indicated using the HTTP Content-Type header. Provide informative error messages and a means of navigating away from an error message back to useful information. Do not rely on cookies being available. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies and others simulate cookies on behalf of mobile devices. Test that cookies are supported by the device on its current access path. If they are not supported, use URI decoration for session management. Provide caching information in HTTP responses. Limited bandwidth and high latency can reduce the usability of Web sites on mobile devices. Using caching information effectively can reduce the need to reload data such as style sheets, images and pages, thus improving performance and reducing cost of use. It can also prevent the reuse of content where this is not appropriate, for example content that is adapted for one device should not be re-used by different devices. User agents and network caches are both affected by caching information. Do not rely on support of font related styling. Mobile devices often have few fonts and limited support for font sizes and effects (bold, italic etc.) As a result of this, the use of font size, face or effect, for example to highlight an answer or a stressed word, may not achieve the desired effect. 40 . Best practices: user input Keep the number of keystrokes to a minimum. Avoid free text entry where possible. Provide pre-selected default values where possible. Specify a default text entry mode, language and/or input format, if the target device is known to support it. User input is typically more difficult on a mobile device than on a PC. Where possible, use selection lists, radio buttons and other controls that do not require typing. Where possible use previous entries as defaults. Make it possible to select items using navigation keys and/or numeric input. Create tab order through links, form controls and objects. It is important that as the user navigates through the page the various fields and objects are presented in a logical order, especially as many of them will not be visible at the same time as the focus item. Label all controls appropriately and explicitly associate labels with controls. Position labels so they lay out properly in relation to the controls they refer to. This means use the label element in HTML, or its equivalent in other languages. Make sure that where the label goes is consistent and close to the control so re-flowing or adapting the content intelligently will always recognize label controls and keep them together. 41 So, in summary, best practices are not required, but certainly are highly recommended. In addition, there is an online wiki, titled Shared Techniques wiki for the W3C Mobile Web Initiative Best Practices, which offers further insights and techniques on the W3C best practices. 42 Dreamweaver, from Adobe, is an XHTML editor that you may be interested in using for creating your dotMobi pages. It has a WYSIWYG interface that allows you to write XHTML code quickly and accurately. It also has a validation option for checking your code, and a preview in browser option for quickly testing your page in a browser. On the following slide is a recording that shows just how easy it is to create a dotMobi page using Dreamweaver. 43 Dreamweaver demo shown 44 Another tool that may be useful to you as you build out your dotMobi site, is the Firefox User Agent Switcher extension. If you decide to make your web server dynamic so that it sends pages specific to the device making the url request, (look on the developer site for an article coming soon that describes how to set up your web server to do that), then you may be interested in the Firefox User Agent Switcher extension. The Firefox User Agent Switcher extension allows your browser to fool the web server into thinking the browser is a specific mobile device. This allows you to have a quick way to test what pages your server sends back for various mobile devices. 45 The Firefox User Agent Switcher extension works by having Firefox send the user agent line of code for a specific mobile device instead of the normal Firefox user agent line of code. 46 The User Agent Switcher extension is free to download and install. Once you’ve installed it, you can set up user agents. 47 To set up user agents for specific mobile devices, choose Tools – User Agent Switcher – Options – Options, then click on the Add button, type in a name for the user agent, and then type or paste in the user agent string. . 48 In order to set up user agents in the Firefox extension, you’ll need to know the specific user agent strings for the mobile devices that you want to be able to test for. Zytrax.com has a list of user agent strings for many mobile devices. 46 Once you’ve added a user agent to the Firefox extension, you can select it from the extension menu and browse to the URL of the mobile page that you want to test. The web server will return the version of the page that’s been set up for that specific device. 49 To make accessing the user agent extension menu even more convenient, you can add it to your Firefox toolbar. Right-click on the toolbar, choose Customize, and then drag the user agent extension icon to the toolbar. 50 Another aspect of creating your dotMobi site that you may want to consider is the Google Mobile Web Search. On its mobile site, Google has a Mobile Web Search option that allows users to search the mobile web. In order to improve your dotMobi site’s position on the search results page, you can submit to Google a Mobile Sitemap for your site. 51 Google details how to create a Mobile Sitemap in the Google Webmaster Help Center. Basically, you can manually create the sitemap or use the Sitemap Generator. 50 Along with this course and the dotMobi Switch On! Web Developer Guide, an additional resource available to you as you build out your dotMobi site, is dev.mobi. dev.mobi, located at http://dev.mobi, is an online developer forum serving creators of mobile content worldwide. The forum is designed to be a central location where developers can find tools and resources to help them build useful and compelling mobile services for their users. Dev.mobi provides technical articles written by industry experts and real life case studies of existing mobile sites to help existing web developers that are not familiar with the mobile web to adapt to this new channel. Dev.mobi also hosts interactive forums so that you can browse existing conversations and, by creating a developer account (at no charge) and logging in, submit your questions to the dotMobi developer community. In addtion, dev.mobi provides up-to-the-minute mobile industry news and links to other useful resources on the Internet. 52 Thank you for taking the time to go through this course. If you’d like to go back through any of the topics, you can press the refresh button in your browser to start over, or use the Outline tab on the right-hand side of the course window to jump to a specific page. We hope this has been useful, and we look forward to seeing your dotMobi site on the mobile web. END ř ű }35‚„•—ăĺ[]km   ńňôö%(*+/CDHĺćN"O"S"×$Ř$Ü$Ž(É*Ę*Ě*Í*Ď*,,,,G.H.M.ł0ś0ť0u2w2y2|2W4Y4^4ŕ5â5ĺ5š6ť6˝6Ŕ67‘799==AFCFNOüřôřôđôđôđôđôđôđôđôđřđřěđěřôčôčřáčřôđčđřôđřđôđôđřđÝôřôŮřčŮřÝôŐřŐÝřÝŐřŐÝŐřŐÝŐÝŐŃŐŃŐhŻ`Ľh [¸hI^ŁhŃV hÜR`hÜR`hÜR`h^dmhýwh ­h˙;ˆhˆ*R YZ‡ˆâă] ^ Ű Ü \ ] ă ä ÷ ř ű ś ˇ ż Ŕ    N O úúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd ­2ŽţO ijVWÍÎĐghŠ‹ëě}~éę3457‘’ úúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd ­  ‚ƒ„†•–—™žŸŔÁăäĺčžż[\]`úúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd ­jklmpqr  ŤŹz{ňóô÷STÇČ)*+/úúúúúúúúúúúőőőőőőúúúúúúúúúúúgd^dmgd ­/CDHĺć8 9 ’ “ !!"!”!•!M"N"O"P"Q"T"@#A#9$:$×$Ř$Ü$É%Ę%úúúúúőőőőőőőőőúúúúúúúúúúđđđđgdýwgdÜR`gd ­Ę%Ú&Ű&((­(Ž(ą(H)I)ś)ˇ) * *É*Ę*Ď*D+E+¤+Ľ+,,,,,ë,ě,{-úúúúúőőőőőőőőőőúúúúúúőőőőőőőgd ­gdýw{-|-G.H.M.Ÿ. .ů.ú.ˆ/‰/ű/ü/´0ľ0ś0ş011‡1ˆ1Đ1Ń1v2w2|233úúúőőőőőőőőőőúúđđđđđđđđúëëëgd [¸gdŃVgdÜR`gd ­3Q3R3W4X4Y4^4ô4ő4‘5’5Ţ5ß5ŕ5ĺ566š6ş6ť6Ŕ6ń6ň677‘7”7ţ7˙7úúúúúőőőőőőúúúúúúúúúúúúúúúúúgdŃVgd [¸˙7‰8Š899997989ť9ź9: :Ć:Ç:;;#<$<d<e<==J=K==Ž==’=ˇ=úúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd [¸ˇ=¸=ă=ä=¨>Š>â>ă>ő?ö?@@×AŘA\B]BˆB‰BćBçBöC÷CsDtDÎDĎD°EąEFFúúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd [¸FAFBFCFFFFŽFůGúGMHNH´HľH'I(I˘IŁI&J'J“J”JöJ÷JyKzK'M(M0N1NnNúúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd [¸nNoNNOOOPOSO{O|OşOťOŰOÜO P PQQMQNQŤQŹQNRORűRüRMSNSsTtTU Uúúúúúúúúúúúúúúúúúúúúúúúúúúúúúgd [¸NOPOU U"UşXźXŃ[Ň[Ő[w`z`ČfĘfÝißi-p/p1pw w"w$w%w&|(|*|A}C}E} "$ǁȁ́„‚…‚†‚ˆ‚‰‚ƒƒƒƒĺƒçƒęƒěƒä…ĺ…ç…é…Ædž#ˆ'ˆťŒ˝ŒžŒ2ŽüřôđôđôđěđěđěôěôđěôđěôĺôđěáÝěáÝěáěáŮěŇŮáěáŮěáŮŇŮáěáÝÎěáěáěáěáĘhëD°h)mÇ hAFhAFhAFh n$h ţ hëočhëočh“Mžh=0Âhëočh [¸hŻ`Ľ> U!U"U%U„U…U˙VW"W#W˝WžW X XdXeXšXşXťXźXżXßXŕX YYßYŕY,Z-Zúúúőőőőőőőőőőőőőőőőőőőőőőőőőgdëočgd [¸-ZœZZŰZÜZöZ÷Z[[T[U[Đ[Ń[Ň[Ő[ \ \7\8\]]Y]Z]˜]™]U^V^”^•^úúúúúúúúúúúúúőőőőőőőőőőőőőőőgd=0Âgdëoč•^___‚_v`w`z`ß`ŕ`"a#aŒˇŒ¸ŒšŒşŒťŒžŒ÷ŒřŒËĚ-Ž2ŽúúúúúúúúúúúúúúúúúúőőőőőőgdëD°gd ţ,1h°Đ/ °ŕ=!°"°# $ %°°Đ°Đ Đ†œ@@ń˙@ NormalCJ_HaJmH sH tH DA@ň˙ĄD Default Paragraph FontRi@ó˙łR  Table Normalö4Ö l4Öaö (k@ô˙Á(No List2†Â˙˙˙˙ YZ‡ˆâă]^ŰÜ\]ăä÷řűśˇżŔNOijVWÍÎĐgh  Š ‹  ë ě } ~   é ę 3 4 5 7 ‘ ’ ‚ ƒ „ †   • – — ™ žŸŔÁăäĺčžż[\]`jklmpqr  ŤŹz{ňóô÷STÇČ)*+/CDHĺć89’“!"”•MNOPQT@A9:×ŘÜÉĘÚŰ  ­ Ž ą H!I!ś!ˇ! " "É"Ę"Ď"D#E#¤#Ľ#$$$$$ë$ě${%|%G&H&M&Ÿ& &ů&ú&ˆ'‰'ű'ü'´(ľ(ś(ş())‡)ˆ)Đ)Ń)v*w*|*++Q+R+W,X,Y,^,ô,ő,‘-’-Ţ-ß-ŕ-ĺ-..š.ş.ť.Ŕ.ń.ň.//‘/”/ţ/˙/‰0Š011117181ť1ź12 2Ć2Ç233#4$4d4e455J5K55Ž55’5ˇ5¸5ă5ä5¨6Š6â6ă6ő7ö788×9Ř9\:]:ˆ:‰:ć:ç:ö;÷;s<t<Î<Ď<°=ą=>>A>B>C>F>>Ž>ů?ú?M@N@´@ľ@'A(A˘AŁA&B'B“B”BöB÷ByCzC'E(E0F1FnFoFNGOGPGSG{G|GşGťGŰGÜG H HIIMINIŤIŹINJOJűJüJMKNKsLtLM M!M"M%M„M…M˙NO"O#O˝OžO P PdPePšPşPťPźPżPßPŕP QQßQŕQ,R-RœRRŰRÜRöR÷RSSTSUSĐSŃSŇSŐS T T7T8TUUYUZU˜U™UUVVV”V•VWWW‚WvXwXzXßXŕX"Y#Y„ˇ„¸„š„ş„ť„ž„÷„ř„Ë…Ě…-†4†˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€Ü\]ă䜡żŔNjVWÍĐgh   ë ě }  é ę 3 7 ‘ ’ ‚ †   žŸŔÁčžż[`jkpqr ŤŹz{ň÷STÇČ)*+C8“!"”•MT@A9:ÉĘÚŰ  ­ H!I!ś!ˇ! " "D#E#¤#Ľ#$ë$ě${%|%Ÿ&ú&ˆ'‰'ű'ü'´(ś())‡)ˆ)Đ)Ń)v*w*++Q+R+Y,ô,ő,‘-’-Ţ-..š.ń.ň.”/ţ/˙/‰0Š071e455J5K5ˇ5Ď<°=ą=>>>(E0F1FnFoF{GüJMKNKsLtL„MžO P PdPePßPSTSUSĐSŃS T•VWWW‚WvXßX’]Ů]Ú]^^Ç^ë^#a`aaaÜaÝaEbřf?g@gugvgĄhýkďmđm n!n@otrÄrĹrss&t+t‚tƒtˇu¸u“v”vwžwÎx[y\yÇyČy„z…z†z‰zĚzÍz{{{{ĺ{ę{í{—|˜|Ý|ŕ|ƒ}„}ä}ĺ}ę}X~Y~Č~56œ#€(€{€|€É€Ě€miƒ=„>„ˇ„¸„š„ş„ť„÷„ř„Ë…Ě…-†4†Kˆ0pĹIˆ0€Iˆ0€Iˆ0€š@0€€€Kˆ0&ĹIˆ0€Iˆ0€Iˆ0€š@0€€€Kˆ0  ˜–Iˆ0 €Iˆ0 €Iˆ0€Kˆ0Ŕ"–˜@0€€PIˆ0€Iˆ0€Iˆ0€Kˆ0”/–˜@0€€€Iˆ0€Iˆ0€Kˆ00–˜@0€€ˆIˆ0€Iˆ0€Kˆ0ü4–˜@0€€řIˆ0€Iˆ0€Iˆ0€Iˆ0!€Kˆ0!€˜@0€€€Iˆ0€š@0€€ˆKˆ0&',K–Iˆ0&€Iˆ0&€Iˆ0€Iˆ0€Kˆ0+,Hg–˜@0€€Iˆ0,€Iˆ0€Kˆ0/€˜@0€€€Iˆ0€Kˆ023 h–Iˆ02€Kˆ02€Iˆ0€Iˆ0€Kˆ0EäFÔ -š@0€€€Iˆ0FáIˆ0G€Iˆ0G€Iˆ0G€Kˆ0GH`(–˜@0€€ˆIˆ0H€Iˆ0€Iˆ0€Kˆ0€Kˆ0€IČ0Ŕ€KČ0Ŕ€KČ0Ŕ€Kˆ0[Ň\<-Iˆ0[ŃIˆ0[Ď˜@0€€€Iˆ0R€Iˆ0R€Kˆ0RS”)–˜@0€€€Iˆ0S€Iˆ0€Iˆ0€š@0€€€Kˆ0`˛aČ-Iˆ0`ąIˆ0`ŻIˆ0X€˜@0€€€˜@0€€€˜@0€€€Kˆ0XYŒ§–Iˆ0X€Iˆ0X€Iˆ0€Iˆ0€š@0€€€Iˆ0sŁIˆ0d ˜@0€€ ˜@0€€ š@0€€ Kˆ0deܨ–Iˆ0d€Iˆ0d€š@0€€Kˆ0}Ż~ô-Iˆ0}ŽIˆ0}Ź˜@0€€€Iˆ0€Iˆ0€Iˆ0€š@0€€@Kˆ0~œ-Iˆ0~›Iˆ0~™Iˆ0€Iˆ0€Iˆ0€Iˆ0€š@0€€ˆIˆ0u€Iˆ0€Iˆ0€Kˆ0ŠŠ‹`-š@0€€€Iˆ0‹‡˜@0€€€Iˆ0~€Iˆ0~€š@0€€€Iˆ0€Iˆ0‚€š@0€€€Iˆ0€Kˆ0†‡¨KĹ˜@0€€€Iˆ0‡€Iˆ0€Iˆ0€š@0€€€Kˆ0ŒĐŒĹIˆ0Œ€Iˆ0Œ€Iˆ0€Iˆ0€š@0€€€Kˆ0’“xĹIˆ0’€Iˆ0’€Iˆ0€Iˆ0€š@0€€Kˆ0˜™ ŽĹIˆ0˜€Iˆ0˜€Iˆ0€Iˆ0€š@0€€Kˆ0žŸČŽĹIˆ0ž€Iˆ0ž€Iˆ0€Iˆ0€š@0€€€Kˆ0¤ĽpĹIˆ0¤€Iˆ0¤€Iˆ0€Iˆ0€š@0€€HKˆ0ŞŤwIˆ0Ş€Iˆ0Ş€Iˆ0€Iˆ0€š@0€€€Kˆ0ÁZÂd-Iˆ0ÁYIˆ0ÁWIˆ0°˜@0€€˜@0€€š@0€€€Kˆ0ČZÉ(-Iˆ0ČYIˆ0ČWIˆ0°˜@0€€˜@0€€š@0€€Kˆ0°ą¸wIˆ0°Iˆ0°Iˆ0€Iˆ0€š@0€€€Kˆ0śˇ`xIˆ0śIˆ0śIˆ0€Iˆ0€KČ0Kˆ0ź˝yIˆ0źIˆ0źIˆ0€Iˆ0€KČ0Kˆ0ÂĂ°yIˆ0ÂIˆ0ÂIˆ0€Iˆ0€Iˆ0ÇKˆ0ǘ@0€€Iˆ0€š@0€€ˆKˆ0ĚÍČzIˆ0ĚIˆ0ĚIˆ0€š@0€€(Kˆ0ŃŇT{Iˆ0ŃIˆ0ŃIˆ0€Iˆ0€Kˆ0€Iˆ0€Iˆ0€Kˆ0ő-˜@0€€€Iˆ0€Iˆ0€Iˆ0€Kˆ0€Iˆ0€Iˆ0€Iˆ0€Kˆ0ŕ˜@0€€ŔIˆ0€Iˆ0ăIˆ0ă˜@0€€@Iˆ0€Iˆ0çIˆ0çKˆ0ç˜@0€€Iˆ0€Kˆ0ëě ˜@0€€Iˆ0ěIˆ0€Iˆ0€Iˆ0đKˆ0đ˜@0€€Iˆ0€Iˆ0€Iˆ0€š@0€€Kˆ0÷řpIˆ0÷Iˆ0÷Iˆ0€Iˆ0€Iˆ0€Iˆ0€Iˆ0€š@0€€ŔKˆ0l Iˆ0Iˆ0Iˆ0€Kˆ0€NO2ŽHVO /Ę%{-3˙7ˇ=FnN U-Z•^fˆj{q?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`aţ˙˙˙cdefghiţ˙˙˙klmnopqrstuvwxyz{|}~€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ Ą˘Ł¤ĽŚ§¨ŠŞŤţ˙˙˙­ŽŻ°ą˛łţ˙˙˙ľśˇ¸šşťţ˙˙˙ý˙˙˙ý˙˙˙żţ˙˙˙ţ˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙Root Entry˙˙˙˙˙˙˙˙ ŔFpěöšÂ/ĚÁ€Data ˙˙˙˙˙˙˙˙˙˙˙˙b1Table˙˙˙˙jŒ‚WordDocument˙˙˙˙.ÂSummaryInformation(˙˙˙˙˙˙˙˙˙˙˙˙ŹDocumentSummaryInformation8˙˙˙˙˙˙˙˙´CompObj˙˙˙˙˙˙˙˙˙˙˙˙q˙˙˙˙˙˙˙˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ţ˙ ˙˙˙˙ ŔFMicrosoft Office Word Document MSWordDocWord.Document.8ô9˛q