<?xml version="1.0" encoding="utf-8"?>
<!-- generator="FeedCreator 1.7.2-ppt DokuWiki" -->
<?xml-stylesheet href="http://www.mobiledesign.org/lib/exe/css.php?s=feed" type="text/css"?>
<rdf:RDF
    xmlns="http://purl.org/rss/1.0/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel rdf:about="http://www.mobiledesign.org/feed.php">
        <title>Mobile Design &amp; Development by Brian Fling</title>
        <description></description>
        <link>http://www.mobiledesign.org/</link>
        <image rdf:resource="http://www.mobiledesign.org/lib/images/favicon.ico" />
       <dc:date>2012-05-25T12:52:12-07:00</dc:date>
        <items>
            <rdf:Seq>
                <rdf:li rdf:resource="http://www.mobiledesign.org/a_brief_history_of_mobile?rev=1301376902&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/a_brief_history_of_webkit?rev=1299652034&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/about?rev=1300047626&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/access_to_devices?rev=1300042165&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/accessing_the_filesystems?rev=1299651651&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/adapting_to_devices?rev=1300146693&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/add_advertising?rev=1299652656&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/adding_an_icon?rev=1300037420&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/addressable_mobile_market?rev=1299915781&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/admob_and_google_adsense?rev=1300041041&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/ajax?rev=1299993852&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/and_many_more?rev=1299652462&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/andy_moore_s_mobile_browser_detection?rev=1299652386&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/application_context?rev=1299966395&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/application_context_matrix?rev=1299973063&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/application_frameworks?rev=1299914217&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/applications?rev=1299650983&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/arpu?rev=1299652624&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/background_as_a_mobile_browser?rev=1299991480&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/basic_box_properties?rev=1299989865&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/believe_what_you_see_not_what_you_read?rev=1299961241&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/bobo?rev=1299652632&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/box_model?rev=1299989310&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/carrier_is_the_new_c_word?rev=1299651759&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/changing_the_status_bar_appearance?rev=1300037280&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/charging_for_it?rev=1299651610&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/clickstreams?rev=1299979841&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/collecting_user_agents?rev=1300043352&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/color?rev=1299983961&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/color_and_backgrounds?rev=1299990462&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/constraints_never_come_first?rev=1299961328&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/consumer_expectations?rev=1299651586&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/context?rev=1299982967&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/context_with_a_capital_c?rev=1299969309&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/context_with_a_lowercase_c?rev=1299969365&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/control?rev=1299651577&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/creating_a_game?rev=1299651618&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/creating_a_mobile_web_app?rev=1300035622&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/creating_a_test_plan?rev=1300042373&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/creating_a_test_portal?rev=1300042731&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/creating_links?rev=1299988892&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/credits?rev=1300048455&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/css?rev=1299651932&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/css2?rev=1299992496&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/css3?rev=1299993092&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/css_iphone?rev=1299652095&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/deciding_what_to_support?rev=1300041244&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/defining_the_viewport?rev=1300036811&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_context?rev=1299968162&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_different_screen_sizes?rev=1299986287&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_multiple_displays?rev=1299987836&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_multiple_mobile_browsers?rev=1299684716&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_the_best_possible_experience?rev=1299651440&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/designing_for_the_right_device?rev=1299651526&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/desktop_testing?rev=1300042815&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/developing_a_mobile_strategy?rev=1299960899&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/device_plans?rev=1299987884&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/device_targeting?rev=1300039163&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/device_testing?rev=1299652719&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/deviceatlas?rev=1300039694&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/devices?rev=1299968021&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/dhtml?rev=1299993797&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/dial?rev=1299651818&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/different_ia_for_different_devices?rev=1299980326&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/do_nothing?rev=1299652307&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/document_structure?rev=1299988396&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/domain_folders?rev=1300040114&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/don_t_convert_create?rev=1299651168&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/dotmobi?rev=1300040189&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/dotmobi_wordpress_mobile_pack?rev=1300039516&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/estimating_the_testing_effort?rev=1300042322&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/example_device_plans?rev=1300041358&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/firefox?rev=1300043246&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/five_assumptions_about_one_web?rev=1299652316&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/fixed_footer?rev=1300035748&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/focus_on_context_goals_and_needs?rev=1299651152&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/font_and_text_properties?rev=1299989738&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/forget_what_you_think_you_know?rev=1299651124&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/forms?rev=1299989099&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/fragmentation?rev=1299651559&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/frames?rev=1299651908&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/frames_testing?rev=1300042859&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/full-screen_mode?rev=1300036853&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/full_adaptation?rev=1299652470&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/games?rev=1299964079&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/graphics?rev=1299985439&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/greg_mulmash_s_mobile_browser_detection?rev=1300039364&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/having_a_device_plan?rev=1300041173&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/home?rev=1301376605&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/htaccess-based_device_detection?rev=1300039421&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/html5?rev=1299992312&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/images_and_objects?rev=1299988947&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/immersive_full-screen_applications?rev=1299966861&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/in_the_beginning?rev=1301376923&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/information_applications?rev=1299966727&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/interpreting_design?rev=1299651422&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/invent_a_new_model?rev=1299652679&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/iphone_gui_psd?rev=1300037632&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/iphone_web_apps?rev=1299652017&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/iui?rev=1300037695&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/javascript-based_device_detection?rev=1299652422&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/javascript?rev=1299990669&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/javascript_iphone?rev=1299652129&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/javascript_is_the_next_frontier?rev=1299651729&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/jqtouch?rev=1300037759&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/keep_it_simple?rev=1299651177&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/keeping_it_simple?rev=1299979244&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/layering_multiple_stylesheets_for_multiple_devices?rev=1299652361&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/layout?rev=1299983579&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/locale_context?rev=1299966658&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/look_and_feel?rev=1299983318&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/making_money_in_mobile?rev=1300040389&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/markup?rev=1299651852&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/markup_iphone?rev=1299652068&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/message?rev=1299983107&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobify?rev=1300039911&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_2.0?rev=1299651681&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_application_media_matrix?rev=1299964147&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_application_medium_types?rev=1299962327&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_as_a_medium?rev=1299915945&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_design?rev=1299982422&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_design_tent-pole?rev=1299982835&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_design_tools?rev=1299985474&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_fu?rev=1300039545&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_ia?rev=1299979169&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_information_architecture?rev=1299973119&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_needs_to_check_its_ego?rev=1299651768&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_usability_test_tips_and_tricks?rev=1299652834&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_web_applications?rev=1299963867&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_web_applications_are_the_future?rev=1299651720&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_web_apps_versus_native_applications?rev=1299651543&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_web_development?rev=1299987354&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_web_widgets?rev=1299963742&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_websites?rev=1299963575&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobile_widgets_are_the_next_big_thing?rev=1299651752&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/mobileaware?rev=1300039988&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/multitouch?rev=1300035485&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/native_applications?rev=1299963973&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/netbiscuits?rev=1300039901&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/networks?rev=1299913378&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/new_rules?rev=1299960948&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/offline_users?rev=1299651662&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/opera?rev=1300042959&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/operating_systems?rev=1299914165&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/operators?rev=1299913403&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/other_recommendations?rev=1299989134&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/phonegap?rev=1300037548&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/platforms?rev=1299913901&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/positioning_and_page_flow?rev=1299990583&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/preface?rev=1300048283&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/productivity_applications?rev=1299966794&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/progressive_enhancement?rev=1300039058&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/progressive_enhancement_overview?rev=1299987765&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/promo?rev=1300047796&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/prototyping?rev=1299980352&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/remote_access?rev=1300044494&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/reverse_device_detection?rev=1300039455&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/rich_interactions_kill_battery_life?rev=1299651736&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/selectors?rev=1299989558&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/services?rev=1299650992&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/simulators_and_emulators?rev=1300043587&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/site_maps?rev=1299979538&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/size_and_scope_of_the_mobile_market?rev=1299915722&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/sms?rev=1299963381&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/subdomains?rev=1300040032&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/supporting_devices?rev=1299652687&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/tables?rev=1299988999&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/taking_next_steps?rev=1299960847&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/taking_the_next_step?rev=1299652591&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/text_elements?rev=1299988745&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_brick_era?rev=1299967910&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_candy_bar_era?rev=1301377009&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_convergence_of_the_web_and_mobile?rev=1299651704&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_deck?rev=1300040720&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_design_myth?rev=1299982325&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_device_detection_dilemma?rev=1299652378&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_device_matrix?rev=1299987923&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_eighth_mass_medium?rev=1299651040&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_elements_of_mobile_design?rev=1299651448&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_evolution_of_devices?rev=1301376947&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_feature_phone_era?rev=1301377080&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_future_of_mobile?rev=1300044571&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_handheld_media_type?rev=1300039098&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_mobile_ecosystem?rev=1299912990&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_mobile_marketing_association?rev=1300041085&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_mobile_user_experience_is_awful?rev=1299651744&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_mobile_web_browser_as_the_next_killer_app?rev=1299651713&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_one_web_aftermath?rev=1299652326&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_opportunity_for_change?rev=1300044890&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_page_model?rev=1299652059&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_smartphone_era?rev=1301377182&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_switcher?rev=1299652406&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_touch_era?rev=1299911903&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_ubiquity_principle?rev=1299986661&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/the_web?rev=1299651568&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/thinking_in_context?rev=1299651067&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/toc?rev=1299650758&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/tools_and_libraries?rev=1299652229&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/types_of_mobile_applications?rev=1299651185&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/typography?rev=1299984398&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/ubiquity_in_the_mobile_web?rev=1299651594&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/ubiquity_starts_with_the_mobile_web?rev=1299959241&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/usability_testing?rev=1300044468&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/using_accelerometers?rev=1299651642&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/using_cameras?rev=1299651634&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/using_specific_locations?rev=1299651625&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/using_this_strategy_with_media_queries?rev=1299652334&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/utility_context?rev=1299966589&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/visual_effects?rev=1299993691&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/volantis?rev=1299652514&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/wall_and_wng?rev=1299652522&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/we_are_creator_not_consumers?rev=1299987225&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/web_apps_as_native_app?rev=1300037468&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/web_standards?rev=1299651792&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/webkit?rev=1300043121&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/what_about_the_mobile_web?rev=1300040870&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/what_domain_do_i_use?rev=1300039942&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/what_is_information_architecture?rev=1299973664&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/what_is_mobile_2.0?rev=1299651690&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/what_makes_it_a_mobile_web_app?rev=1299991518&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/when_to_make_a_mobile_web_application?rev=1299651671&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/when_to_make_a_native_application?rev=1299986894&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/why_is_adaptation_a_necessity?rev=1300038712&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/why_mobile?rev=1299651002&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/why_webkit?rev=1299652025&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/wireframes?rev=1299980009&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/wireless_css_and_css-mp?rev=1299651940&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/wordpress_mobile_plug-in?rev=1300039490&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/working_off_deck?rev=1299652487&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/working_on_deck?rev=1299652479&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/working_with_an_app_store?rev=1300040818&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/working_with_operators?rev=1300040440&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/wurfl?rev=1299652495&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/xhtml-mp_overview?rev=1299987972&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/xhtml?rev=1299991902&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/yahoo_blueprint?rev=1300039811&amp;do=diff"/>
                <rdf:li rdf:resource="http://www.mobiledesign.org/you_can_t_support_everything?rev=1299651160&amp;do=diff"/>
            </rdf:Seq>
        </items>
    </channel>
    <image rdf:about="http://www.mobiledesign.org/lib/images/favicon.ico">
        <title>Mobile Design &amp; Development by Brian Fling</title>
        <link>http://www.mobiledesign.org/</link>
        <url>http://www.mobiledesign.org/lib/images/favicon.ico</url>
    </image>
    <item rdf:about="http://www.mobiledesign.org/a_brief_history_of_mobile?rev=1301376902&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:35:02-07:00</dc:date>
        <title>A Brief History of Mobile</title>
        <link>http://www.mobiledesign.org/a_brief_history_of_mobile?rev=1301376902&amp;do=diff</link>
        <description>I like to compare the history of the mobile industry to the work of Umberto Eco: you get what is going on, but it makes your head hurt in the process. The evolution of mobile networks, the devices that run on them, and the services we use every day have evolved at an amazing rate, from the early phones that looked more like World War II field radios to the ultra-sleek fashion statements of today.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/a_brief_history_of_webkit?rev=1299652034&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:27:14-07:00</dc:date>
        <title>A Brief History of WebKit</title>
        <link>http://www.mobiledesign.org/a_brief_history_of_webkit?rev=1299652034&amp;do=diff</link>
        <description>WebKit is an open source web browser engine derived by Apple from the Konqueror HTML layout engine called KHTML and its KJS JavaScript engine. Apple ported KHTML and KJS to Mac OS X to create the first Safari desktop browser in 2003 and has since been used in a number of Mac OS X applications.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/about?rev=1300047626&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T13:20:26-07:00</dc:date>
        <title>About the Author</title>
        <link>http://www.mobiledesign.org/about?rev=1300047626&amp;do=diff</link>
        <description>Brian Fling is an authority in the field of  in mobile user experience and designing for multiple contexts. He has worked with hundreds of businesses from early stage start-ups to Fortune 50 companies to leverage a variety of mediums, like mobile devices, to design for the needs and context of real people.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/access_to_devices?rev=1300042165&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:49:25-07:00</dc:date>
        <title>Access to Devices</title>
        <link>http://www.mobiledesign.org/access_to_devices?rev=1300042165&amp;do=diff</link>
        <description>FIG 15-1With Urban Spoon you shake to produce a result—something that is hard to test for without an actual device

Gaining access to multiple devices is a challenge for every mobile design and developer. I recommend that everyone involved has at least one device, indicative of your primary device class, on the desk when working on the project. This will dramatically reduce the number of assumptions that you have to make during the design and development of the product and can ultimately reduce …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/accessing_the_filesystems?rev=1299651651&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:51-07:00</dc:date>
        <title>Accessing the Filesystems</title>
        <link>http://www.mobiledesign.org/accessing_the_filesystems?rev=1299651651&amp;do=diff</link>
        <description>Another reason you would want to create a native application is if you want to use the data stored on the device itself. This might be the user’s address book, photos, an email message, or even data from another application.

Such filesystem access is obviously a big security and privacy issue. An errant application potentially could alter or delete your data, or worse. An infected application could use your contacts and constant connection to spread a virus to multiple phones, something that oc…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/adapting_to_devices?rev=1300146693&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-14T16:51:33-07:00</dc:date>
        <title>Adapting to Devices</title>
        <link>http://www.mobiledesign.org/adapting_to_devices?rev=1300146693&amp;do=diff</link>
        <description>Not all mobile devices are created equal. Thus the age-old problem in mobile design and development: devices can be vastly different from each other. It would be easy if different devices simply supported different attributes—one supports CSS3 and one doesn’t. But it isn’t that easy. One device might support CSS3 and another device might support CSS3 poorly—or worse, incorrectly.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/add_advertising?rev=1299652656&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:37:36-07:00</dc:date>
        <title>Add Advertising</title>
        <link>http://www.mobiledesign.org/add_advertising?rev=1299652656&amp;do=diff</link>
        <description>The third strategy is to add advertising to your content. Using this model on the mobile web, you are fully in control with no outside dependencies: no negotiation with operators, no app store certification, and no application containers. As mentioned before, the revenue earned from mobile advertising completely depends on the amount of traffic you are able to get to your mobile site or web app. Mobile advertising can effectively work in any mobile product, not just a mobile web app. Many free i…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/adding_an_icon?rev=1300037420&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:30:20-07:00</dc:date>
        <title>Adding an Icon</title>
        <link>http://www.mobiledesign.org/adding_an_icon?rev=1300037420&amp;do=diff</link>
        <description>When users bookmark a site or web app on their iPhone, iPhone asks them if they would like to place a link to it on their Home Screen; Apple calls these links Web Clips. When the user chooses to create a Web Clip, the iPhone looks for apple-touch-icon.png or apple-touch-icon-precomposed.png (used in case you don’t want the iPhone to add the gloss effect to the icon) at the root of your site. If found, it will use the icon as the default Web Clip icon. Alternatively, you can define the location u…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/addressable_mobile_market?rev=1299915781&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:43:01-07:00</dc:date>
        <title>Addressable Mobile Market</title>
        <link>http://www.mobiledesign.org/addressable_mobile_market?rev=1299915781&amp;do=diff</link>
        <description>There should be no doubt that the overall mobile market is enormous. The question is, “How many of these users will our product be able to reach?” Unfortunately, this is difficult to answer, because no one knows for sure.

The market isn’t unlike the early days of the Web, a kind of lawless wild frontier in which no one cared about the addressable market; given that the cost of publishing was close to zero, anyone could experiment with the medium. In the mobile market, the cost of publishing can…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/admob_and_google_adsense?rev=1300041041&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:30:41-07:00</dc:date>
        <title>AdMob and Google AdSense</title>
        <link>http://www.mobiledesign.org/admob_and_google_adsense?rev=1300041041&amp;do=diff</link>
        <description>AdMob is a mobile advertising platform that supports PHP and JSP mobile products for mobile web products and provides an SDK specifically for native iPhone applications. The service provides useful reporting and metrics about the performance of your ads.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/ajax?rev=1299993852&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T21:24:12-07:00</dc:date>
        <title>Ajax</title>
        <link>http://www.mobiledesign.org/ajax?rev=1299993852&amp;do=diff</link>
        <description>Making the web application feel lively is half the battle. In most cases, it also has to do something with the data displayed on the page. Enter Asynchronous JavaScript and XML, or Ajax.

With Ajax, the developer can cause events to happen on the server, such as updating records in a database, without causing the page to be refreshed in the browser. This leads to web applications that feel much more responsive. Just like all JavaScript, Ajax can be fired from a variety of conditions, but usually…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/and_many_more?rev=1299652462&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:34:22-07:00</dc:date>
        <title>And Many More...</title>
        <link>http://www.mobiledesign.org/and_many_more?rev=1299652462&amp;do=diff</link>
        <description>This is just the beginning; new solutions to the problems of device targeting are emerging every month. Content management systems and web application frameworks are incorporating mobile templates and logic into their core. I imagine that one day soon, you won’t be able to run a web-based publishing system without the ability to output a mobile version and route devices to it, built right in.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/andy_moore_s_mobile_browser_detection?rev=1299652386&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:33:06-07:00</dc:date>
        <title>Andy Moore’s Mobile Browser Detection</title>
        <link>http://www.mobiledesign.org/andy_moore_s_mobile_browser_detection?rev=1299652386&amp;do=diff</link>
        <description>One of the more popular solutions to provide simple detection is the PHP script written by Andy Moore (&lt;http://www.detectmobilebrowsers.mobi&gt;). Based on the WordPress Mobile Plugin, which he also wrote, this script looks at the requesting user agent string and abstracts the data to match against the majority of mobile devices, then routes it to the mobile version of your site. All you need to do is include the file with the function, then call the function before your PHP pages do anything else:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/application_context?rev=1299966395&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:46:35-07:00</dc:date>
        <title>Application Context</title>
        <link>http://www.mobiledesign.org/application_context?rev=1299966395&amp;do=diff</link>
        <description>Once your application medium is decided upon, it is time to look at the application context, or the appropriate type of application to present to the user in order for the user to process and understand the information presented and complete her goals. Where the application medium refers mostly to the technical approach of creating an application, the application context deals with the user experience. As discussed in Chapter 4, context is the surroundings in which information is processed, and …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/application_context_matrix?rev=1299973063&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T15:37:43-07:00</dc:date>
        <title>Application Context Matrix</title>
        <link>http://www.mobiledesign.org/application_context_matrix?rev=1299973063&amp;do=diff</link>
        <description>I put each of the application contexts into TABLE 6-2, comparing and contrasting their benefits to help you determine what is best for your application.

TABLE 6-2

Application context matrix

 User experience typeTask typeTask durationCombine withUtilityAt-a-glanceInformation recallVery shortImmersiveLocaleLocation-basedContextual informationQuickImmersiveInformativeContent-basedSeek informationQuickLocaleProductivityTask-basedContent managementLongUtilityImmersiveFull screenEntertainmentLongUt…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/application_frameworks?rev=1299914217&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:16:57-07:00</dc:date>
        <title>Application Frameworks</title>
        <link>http://www.mobiledesign.org/application_frameworks?rev=1299914217&amp;do=diff</link>
        <description>Often, the first layer the developer can access is the application framework or API released by one of the companies mentioned already. The first layer that you have any control over is the choice of application framework.

Application frameworks often run on top of operating systems, sharing core services such as communications, messaging, graphics, location, security, authentication, and many others.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/applications?rev=1299650983&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:09:43-07:00</dc:date>
        <title>Applications</title>
        <link>http://www.mobiledesign.org/applications?rev=1299650983&amp;do=diff</link>
        <description>Application frameworks are used to create applications, such as a game, a web browser, a camera, or media player. Although the frameworks are well standardized, the devices are not. The largest challenge of deploying applications is knowing the specific device attributes and capabilities. For example, if you are creating an application using the Java ME application framework, you need to know what version of Java ME the device supports, the screen dimensions, the processor power, the graphics ca…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/arpu?rev=1299652624&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:37:04-07:00</dc:date>
        <title>ARPU</title>
        <link>http://www.mobiledesign.org/arpu?rev=1299652624&amp;do=diff</link>
        <description>Average revenue per user (ARPU, pronounced “are-poo”) is the key performance indicator for all things mobile. As voice ARPU becomes more commoditized, operators look to data ARPU for positive quarterly growth needed to impress shareholders. For example, for users on a post-paid, monthly plan, the more content and services the users access, the higher the data ARPU the operator earns.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/background_as_a_mobile_browser?rev=1299991480&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:44:40-07:00</dc:date>
        <title>Background As a Mobile Browser</title>
        <link>http://www.mobiledesign.org/background_as_a_mobile_browser?rev=1299991480&amp;do=diff</link>
        <description>FIG 12-1The Nokia Web Browser for S60, which is based on WebKit

WebKit’s life as a mobile browser engine did not start at Apple; it started at Nokia, the number-one device maker in the world, long before anyone outside of Apple knew about the iPhone. WebKit is ideal for mobile devices, given its small footprint and capability to render full-scale desktop web designs to mobile devices. And with titans like Apple, Google, and Nokia all returning innovations to the open source project, WebKit mean…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/basic_box_properties?rev=1299989865&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:17:45-07:00</dc:date>
        <title>Basic Box Properties</title>
        <link>http://www.mobiledesign.org/basic_box_properties?rev=1299989865&amp;do=diff</link>
        <description>Being able to style the box area around an element is a crucial part of web standards design. The good news is that the basic CSS level 2 box styling techniques you might use for the desktop web do work on most mobile devices, allowing you to style content with some level of precision. Many of the techniques that are not fully supported, like percentage-based and min-height techniques, are the same ones that many desktop web browsers don’t fully support.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/believe_what_you_see_not_what_you_read?rev=1299961241&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:20:41-07:00</dc:date>
        <title>Believe What You See, Not What You Read</title>
        <link>http://www.mobiledesign.org/believe_what_you_see_not_what_you_read?rev=1299961241&amp;do=diff</link>
        <description>In mobile, any argument can be made, and for a few thousand dollars you can buy a report or white paper that supports your argument. This doesn’t make an argument true, but it certainly can be convincing. And with so many people looking at mobile as an additional revenue stream, but completely clueless as to its inner workings, people are grasping for any information they can find—however inaccurate.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/bobo?rev=1299652632&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:37:12-07:00</dc:date>
        <title>BoBo</title>
        <link>http://www.mobiledesign.org/bobo?rev=1299652632&amp;do=diff</link>
        <description>BoBo means Billing on Behalf of, which allows the operator to bill the consumer on your behalf. With mobile devices, paying for goods or services can be a bit tricky. By the very nature of being mobile, there are common security concerns with transmitting payment information over the air. Although mostly unfounded in newer, more advanced devices, this can certainly be an issue with older devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/box_model?rev=1299989310&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:08:30-07:00</dc:date>
        <title>Box Model</title>
        <link>http://www.mobiledesign.org/box_model?rev=1299989310&amp;do=diff</link>
        <description>FIG 11-3The box model

The box model is one of the key concepts of CSS design, and therefore the first thing that tends to go wrong in mobile devices. The box model is the imaginary box that is around every element in your markup. It consists of five areas: the content, the padding, the border, the margin, and the outer edge, as shown in FIG 11-3.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/carrier_is_the_new_c_word?rev=1299651759&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:39-07:00</dc:date>
        <title>Carrier Is the New &quot;C&quot; Word</title>
        <link>http://www.mobiledesign.org/carrier_is_the_new_c_word?rev=1299651759&amp;do=diff</link>
        <description>I noticed a strong tendency over the years for people in the mobile industry to avoid uttering the word “carrier.” Even the more European equivalent term “operator” seems to be on the decline. To give you an example of how much carriers are hated: you can have entire conversations with people who work for the big operators and even they will avoid using the term in conversation.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/changing_the_status_bar_appearance?rev=1300037280&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:28:00-07:00</dc:date>
        <title>Changing the Status Bar Appearance</title>
        <link>http://www.mobiledesign.org/changing_the_status_bar_appearance?rev=1300037280&amp;do=diff</link>
        <description>In addition, when using apple-mobile-web-app-capable, you can optionally define the status bar style when running web apps in full-screen mode in Mobile Safari. It can be defined as default, black, and black-translucent, which removes the status bar from the page flow, meaning that your content starts at the top of the page, not directly beneath the status bar:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/charging_for_it?rev=1299651610&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:10-07:00</dc:date>
        <title>Charging for It</title>
        <link>http://www.mobiledesign.org/charging_for_it?rev=1299651610&amp;do=diff</link>
        <description>Nowhere is it written that you can’t charge people to use a mobile web app, but for some reason, people think you can’t or shouldn’t. Historically, charging for things on mobile devices has come down to two obstacles:

Payment Input

Entering a credit card number in the mobile device is cumbersome and can be insecure on older devices. Typically, if you want to charge for it, you set up an arrangement with operators to do Billing on Behalf of (BoBo) so purchases just show up on the subscriber’s b…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/clickstreams?rev=1299979841&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:30:41-07:00</dc:date>
        <title>Clickstreams</title>
        <link>http://www.mobiledesign.org/clickstreams?rev=1299979841&amp;do=diff</link>
        <description>FIG 7-7An example clickstream for an iPhone web application

Clickstream is a term used for showing the behavior on websites, displaying the order in which users travel through a site’s information architecture, usually based on data gathered from server logs. Clickstreams are usually historical, used to see the flaws in your information architecture, typically using heat-mapping or simple percentages to show where your users are going. I’ve always found them to be a useful tool for rearchitecti…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/collecting_user_agents?rev=1300043352&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:09:12-07:00</dc:date>
        <title>Collecting User Agents</title>
        <link>http://www.mobiledesign.org/collecting_user_agents?rev=1300043352&amp;do=diff</link>
        <description>FIG 15-9The 100 user agents for just the Motorola RAZR

Test detection and rendering of multiple devices on the desktop means having valid user agents on hand. Given the quantity of devices on the market, there are numerous user agents—sometimes for the same device. The best means of collecting user agents is the open source WURFL database, which contains a large number of user agents submitted by the community and from device makers themselves.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/color?rev=1299983961&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:39:21-07:00</dc:date>
        <title>Color</title>
        <link>http://www.mobiledesign.org/color?rev=1299983961&amp;do=diff</link>
        <description>FIG 8-10An example of different levels of posterization that can occur across multiple device color depths

The fifth design element, color, is hard to talk about in a black-and-white book. Maybe it is fitting, because it wasn’t that long ago that mobile screens were available only in black and white (well, technically, it was black on a green screen). These days, we have nearly the entire spectrum of colors to choose from for mobile designs.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/color_and_backgrounds?rev=1299990462&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:27:42-07:00</dc:date>
        <title>Color and Backgrounds</title>
        <link>http://www.mobiledesign.org/color_and_backgrounds?rev=1299990462&amp;do=diff</link>
        <description>Styling an element means defining colors and background images. Relying on CSS instead of images to create desired visual effects reduces time to download as well as cost.

Background color

The background color allows you to add a color value to the content area of an element. This technique works fairly reliably across all mobile devices:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/constraints_never_come_first?rev=1299961328&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:22:08-07:00</dc:date>
        <title>Constraints Never Come First</title>
        <link>http://www.mobiledesign.org/constraints_never_come_first?rev=1299961328&amp;do=diff</link>
        <description>This is the tricky one, even for the most seasoned mobile expert. Mobile is a highly constrained medium with many technical obstacles. It is hard not to have constraints of the medium, like devices, networks, or frameworks, influence your decisions.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/consumer_expectations?rev=1299651586&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:46-07:00</dc:date>
        <title>Consumer Expectations</title>
        <link>http://www.mobiledesign.org/consumer_expectations?rev=1299651586&amp;do=diff</link>
        <description>My fourth belief is that consumers expect things to just work, and rightfully so. The challenge with native mobile applications is that the consumer may see an application that might look appealing to him, but if it isn’t supported for his particular device, then not only is the sale lost, but often the customer is lost for good. This is one of the reasons that operators usually require applications sold on their marketplace to support their top 10 to 15 devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/context?rev=1299982967&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:22:47-07:00</dc:date>
        <title>Context</title>
        <link>http://www.mobiledesign.org/context?rev=1299982967&amp;do=diff</link>
        <description>I discussed context in Chapter 4. I won’t belabor the point except to say that context is core to the mobile experience. As the designer, it is your job to make sure that the user can figure out how to address context using your app. Make sure you do your homework to answer the following questions:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/context_with_a_capital_c?rev=1299969309&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T14:35:09-07:00</dc:date>
        <title>Context with a Capital C</title>
        <link>http://www.mobiledesign.org/context_with_a_capital_c?rev=1299969309&amp;do=diff</link>
        <description>Context with a capital C is how the users will derive value from something they are currently doing, or in other words, the understanding of circumstance. It is the mental model they will establish to form understanding. For example, standing in front of the remnants of the Berlin Wall and reading about the history on my phone is adding Context to my task. It enhances my experience and awareness of my surroundings in a significant way.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/context_with_a_lowercase_c?rev=1299969365&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T14:36:05-07:00</dc:date>
        <title>Context with a Lowercase c</title>
        <link>http://www.mobiledesign.org/context_with_a_lowercase_c?rev=1299969365&amp;do=diff</link>
        <description>On the other hand, context with a lowercase c is the mode, medium, or environment in which we perform a task or the circumstances of understanding. The following sections look at the three types of context with a little c.

The present location or physical context

FIG_4-9The Android application Wikitude presenting information from the Web in the context the user’s present location</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/control?rev=1299651577&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:37-07:00</dc:date>
        <title>Control</title>
        <link>http://www.mobiledesign.org/control?rev=1299651577&amp;do=diff</link>
        <description>Mobile application distribution cannot and will likely never be under the control of the developer. In other words, mobile application vendors always have to rely on middlemen to get their products to market and take a slice of their profits. This has been the case since the beginning of downloadable mobile applications, when they were under the tight control of the operator.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/creating_a_game?rev=1299651618&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:18-07:00</dc:date>
        <title>Creating a Game</title>
        <link>http://www.mobiledesign.org/creating_a_game?rev=1299651618&amp;do=diff</link>
        <description>If your goal is to create a mobile game—one of the biggest mobile content markets—then you need to create a native application. Games are resource-intensive and almost always require the use of a device or platform API. Although there have been quite a few compelling games created using just web technologies, the competition in the native application game market is just too stiff. When users launch a game, they have some expectations of what it is going to look and act like. The mobile web is cl…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/creating_a_mobile_web_app?rev=1300035622&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:00:22-07:00</dc:date>
        <title>Creating a Mobile Web App</title>
        <link>http://www.mobiledesign.org/creating_a_mobile_web_app?rev=1300035622&amp;do=diff</link>
        <description>Prior to the iPhone, if a site was built for mobile browsers, it was simply referred to as a mobile website, or as web content designed to be viewed within a web browser. Few mobile browsers support the complex interactions that are often associated with web applications, or application-like experiences using web technologies. The iPhone wasn’t the first mobile browser to enable the creation of mobile web applications, but it certainly has had the greatest impact.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/creating_a_test_plan?rev=1300042373&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:52:53-07:00</dc:date>
        <title>Creating a Test Plan</title>
        <link>http://www.mobiledesign.org/creating_a_test_plan?rev=1300042373&amp;do=diff</link>
        <description>Creating a test plan for mobile devices means testing for every possible problem that the phone might encounter and that might result in it failing to present the desired content to the user. Because these devices are never from a fixed list like we are accustomed to with the desktop web, that means this can be a pretty big list of things to test. Multiply that by a larger number of devices and you can start to see that this can take some time.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/creating_a_test_portal?rev=1300042731&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:58:51-07:00</dc:date>
        <title>Creating a Test Portal</title>
        <link>http://www.mobiledesign.org/creating_a_test_portal?rev=1300042731&amp;do=diff</link>
        <description>FIG 15-4An example test portal

A simple but effective trick for mobile web device testing is creating a test portal—basically, a web page with a list of links on it to all your web pages, as shown in FIG 15-4. This provides easy access to all your development servers that you need to test.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/creating_links?rev=1299988892&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:01:32-07:00</dc:date>
        <title>Creating Links</title>
        <link>http://www.mobiledesign.org/creating_links?rev=1299988892&amp;do=diff</link>
        <description>Links are the foundation of how hypertext works. They can take you to new pages or be used as an anchor to content further down the page. With XHTML-MP, links can also initiate a telephone call and perform other device actions in certain phones. However, due to the constrained screen size, there are additional best practices surrounding links.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/credits?rev=1300048455&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T13:34:15-07:00</dc:date>
        <title>Credits</title>
        <link>http://www.mobiledesign.org/credits?rev=1300048455&amp;do=diff</link>
        <description>It amazes me the number of people required to get a book like this into your hands. To say that a book would not be possible without the following people feels like the understatement of a lifetime. I would like to thank all the people who sent me kind words of support throughout the creation of the book. I especially want to call out a few people in particular to whom I owe an enormous debt and my eternal gratitude.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/css?rev=1299651932&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:25:32-07:00</dc:date>
        <title>CSS: Cascading Style Sheets</title>
        <link>http://www.mobiledesign.org/css?rev=1299651932&amp;do=diff</link>
        <description>When we are talking about inconsistencies across multiple mobile devices, what we are really talking about is CSS. In the past, mobile devices had incredibly poor support for CSS, using it as nothing more than a way to style text and apply background colors. Though many of today’s mobile browsers have far better support for both CSS2 and CSS3 than their predecessors, there are still plenty of legacy mobile browsers in the market to contend with.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/css2?rev=1299992496&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T21:01:36-07:00</dc:date>
        <title>CSS2</title>
        <link>http://www.mobiledesign.org/css2?rev=1299992496&amp;do=diff</link>
        <description>FIG 12-9How the iPhone fares with the Web Standards Project’s Acid2 test for CSS2 support

The iPhone has excellent CSS2 support for a mobile browser. In fact, the iPhone might render CSS a bit better than the desktop web browser you’re using these days. Though WebKit and Safari for the desktop support the full CSS2 specification, passing the CSS2 Acid2 test with a 100 percent score (FIG 12-9), Mobile Safari fails on a number of tests, as seen in the following image.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/css3?rev=1299993092&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T21:11:32-07:00</dc:date>
        <title>CSS3</title>
        <link>http://www.mobiledesign.org/css3?rev=1299993092&amp;do=diff</link>
        <description>FIG 12-10The Web Standards Project’s Acid3 test on the iPhone

With most mobile browsers, you need to use lots of images and even tables to create simple visual elements like rounded corners, shadows, and semi-opaque areas. Images add kilobytes, which add time and costs for the user to view, and it is our job to create the fastest and lightest experience possible. This is where CSS3 can come in as a wonderful tool for creating complex designs using the minimum of images, making it ideal for mobi…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/css_iphone?rev=1299652095&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:28:15-07:00</dc:date>
        <title>CSS</title>
        <link>http://www.mobiledesign.org/css_iphone?rev=1299652095&amp;do=diff</link>
        <description>What really makes the iPhone stand apart is its excellent support of CSS and JavaScript. Having desktop-grade CSS support means that you can use the same techniques to create mobile experiences as you would a desktop experience. Not only can the iPhone display a usable version of your site even if it isn’t optimized for mobile devices, but you can also create mobile web apps quickly and easily.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/deciding_what_to_support?rev=1300041244&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:34:04-07:00</dc:date>
        <title>Deciding What to Support</title>
        <link>http://www.mobiledesign.org/deciding_what_to_support?rev=1300041244&amp;do=diff</link>
        <description>As discussed in Chapter 5 regarding the development of a mobile strategy, it is best not to assume that you can support everything. I outlined two methods for determining your support strategy at the beginning of a mobile project. The first is to look at your server logs, seeing which devices currently access your site. The second is to use the niche nature of how devices are marketed to consumers. Device makers make devices with specific consumers in mind—if they are cost-conscious, if they are…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/defining_the_viewport?rev=1300036811&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:20:11-07:00</dc:date>
        <title>Defining the Viewport</title>
        <link>http://www.mobiledesign.org/defining_the_viewport?rev=1300036811&amp;do=diff</link>
        <description>The viewport is the area within a browser where content can be seen by the user. On the desktop, the user can resize the browser window and therefore the viewport. In mobile devices, the browser area cannot be resized; therefore, most Class A browsers—including WebKit and Mobile Safari—create a virtual viewport area, adjusting the content to fit within the screen. By default, Mobile Safari assumes a viewport of 980 pixels, the recommended size for desktop sites.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_context?rev=1299968162&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T14:16:02-07:00</dc:date>
        <title>Designing for Context</title>
        <link>http://www.mobiledesign.org/designing_for_context?rev=1299968162&amp;do=diff</link>
        <description>FIG 4-1My mobile device enhanced my understanding of the landmarks in Berlin, in my own language

In late 2008, I was in Berlin doing a mobile workshop at the Web 2.0 Expo. Having never been to Berlin, I did what I always do in new cities that I visit—I explored. I enjoy just walking aimlessly around a new city with no particular destination or plan. Not only is it a relaxing way to see the sights, but I find amazing things that aren’t on any tour or in any guidebook. There was just one problem …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_different_screen_sizes?rev=1299986287&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:18:07-07:00</dc:date>
        <title>Designing for Different Screen Sizes</title>
        <link>http://www.mobiledesign.org/designing_for_different_screen_sizes?rev=1299986287&amp;do=diff</link>
        <description>FIG 8-20Comparing the various screen sizes

Mobile devices come in all shapes and sizes. Choice is great for consumers, but bad for design. It can be incredibly difficult to create that best possible experience for a plethora of different screen sizes. For example, your typical feature phone might only be 140 pixels wide, whereas your higher-end smartphone might be three to four times wider.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_multiple_displays?rev=1299987836&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:43:56-07:00</dc:date>
        <title>Designing for Multiple Displays</title>
        <link>http://www.mobiledesign.org/designing_for_multiple_displays?rev=1299987836&amp;do=diff</link>
        <description>Next on my list of things to cover is supporting multiple mobile displays. It is both a design and development dilemma, but if you ask any mobile designer, it is quite a painful headache. When trying to design and develop a mobile experience, you have to remember that your design might be viewed on a small 120-pixel screen, common on most lower-end phones, or on a 320-pixel screen common to most smartphones. Depending on the type of devices you plan to support, it is entirely possible that it co…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_multiple_mobile_browsers?rev=1299684716&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-09T07:31:56-07:00</dc:date>
        <title>Designing for Multiple Mobile Browsers</title>
        <link>http://www.mobiledesign.org/designing_for_multiple_mobile_browsers?rev=1299684716&amp;do=diff</link>
        <description>Designing and developing for multiple mobile browsers simultaneously is a challenge, but not an impossibility. It requires looking at your designs and code from many contexts, and being able to visualize how your designs will be rendered on a variety of devices in your head, as you lay down code.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_the_best_possible_experience?rev=1299651440&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:17:20-07:00</dc:date>
        <title>Designing for the Best Possible Experience</title>
        <link>http://www.mobiledesign.org/designing_for_the_best_possible_experience?rev=1299651440&amp;do=diff</link>
        <description>When the first iPhone came out, I got in a lot of trouble from my web and mobile peers for publicly saying, “The iPhone is the only mobile device that matters right now.” They would argue, “What about ABC or XYZ platforms?” My response was that those are important, but the iPhone provides the best possible experience and that is where consumers will go. Since those days, we’ve seen the iPhone shatter just about every record in mobile devices, becoming one of the best-selling phones ever and one …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/designing_for_the_right_device?rev=1299651526&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:18:46-07:00</dc:date>
        <title>Designing for the Right Device</title>
        <link>http://www.mobiledesign.org/designing_for_the_right_device?rev=1299651526&amp;do=diff</link>
        <description>With the best possible experience at hand, take a moment to relish it. Remind yourself that you are working with a rapidly evolving medium and though it might not be possible for every user to experience things exactly the way you’ve intended, you’ve set the tone and the vision for how the application should look. The truly skilled designer doesn’t create just one product—she translates ideas into experiences. The spirit of your design should be able to be adapted to multiple devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/desktop_testing?rev=1300042815&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:00:15-07:00</dc:date>
        <title>Desktop Testing</title>
        <link>http://www.mobiledesign.org/desktop_testing?rev=1300042815&amp;do=diff</link>
        <description>A big advantage of mobile web products is that you can do the majority of your testing from your desktop before ever getting it on a device. You can verify the majority of your markup, styles, and JavaScript, as well doing functional tests on desktop browsers, before putting them on devices and doing your context tests. Desktop testing reduces the time span between developing a feature, testing a feature, and fixing a feature, and ultimately allows you to spend less time dealing with devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/developing_a_mobile_strategy?rev=1299960899&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:14:59-07:00</dc:date>
        <title>Developing  a Mobile Strategy</title>
        <link>http://www.mobiledesign.org/developing_a_mobile_strategy?rev=1299960899&amp;do=diff</link>
        <description>I’ve been trying to stay positive and paint mobile design and development in a positive light. Before I let you in on the secrets of the mobile field—getting into all the dirty details, pitfalls, and frustrations of the medium, and how to solve them, or in some cases how to sidestep them—I want you to remember how important mobile development is to the future. It is the greatest communication and information medium of our time.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/device_plans?rev=1299987884&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:44:44-07:00</dc:date>
        <title>Device Plans</title>
        <link>http://www.mobiledesign.org/device_plans?rev=1299987884&amp;do=diff</link>
        <description>Developing a mobile product means having a device plan at the very start. Effectively, you’ve defined each of your progressive enhancement layers, determining what will be that center, common experience and what layers you intend to support. Unfortunately, I’ve seen it too many times: trouble at the late stages of developing a mobile project because there was no defined device plan. The goal is to get to the test stage without any surprises. Sure, some things might not render properly, but you s…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/device_targeting?rev=1300039163&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:59:23-07:00</dc:date>
        <title>Device Targeting</title>
        <link>http://www.mobiledesign.org/device_targeting?rev=1300039163&amp;do=diff</link>
        <description>The third multiserving strategy is device targeting, or calling out specific devices by class or model and delivering an experience designed with that device in mind. In this strategy, we don’t assume that browsers are trustworthy enough to get to where they need to be. Therefore, in this strategy, the first step of multiserving is to reliably detect the device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/device_testing?rev=1299652719&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:38:39-07:00</dc:date>
        <title>Device Testing</title>
        <link>http://www.mobiledesign.org/device_testing?rev=1299652719&amp;do=diff</link>
        <description>So you have your device plan. Now how do you go about getting devices to test your work on? The simple answer would be to just go buy them, but you guessed it: it isn’t that easy. Many devices are subsidized through the operator. So buying a device at the advertised price means buying into a two-year contract that goes with it. Because you need only one contract per operator, this means you have to pay full price for each device you plan to support. At $500–$600 per device unsubsidized, the cost…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/deviceatlas?rev=1300039694&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:08:14-07:00</dc:date>
        <title>DeviceAtlas</title>
        <link>http://www.mobiledesign.org/deviceatlas?rev=1300039694&amp;do=diff</link>
        <description>dotMobi’s DeviceAtlas is a premium device database service that leverages multiple device databases, including WURFL. DeviceAtlas is meant to be used in one or all of the following ways:

APIAPIW3C

DeviceAtlas can be used in a variety of ways. For example, DeviceAtlas could be used to detect and redirect devices in PHP this way:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/devices?rev=1299968021&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T14:13:41-07:00</dc:date>
        <title>Devices</title>
        <link>http://www.mobiledesign.org/devices?rev=1299968021&amp;do=diff</link>
        <description>FIG 2-2

What you call phones, the mobile industry calls handsets or terminals. These are terms that I think are becoming outdated with the emergence of wireless devices that rely on operator networks, but do not make phone calls. The number of these “other” devices is a small piece of the overall pie right now, but it’s growing rapidly.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/dhtml?rev=1299993797&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T21:23:17-07:00</dc:date>
        <title>DHTML</title>
        <link>http://www.mobiledesign.org/dhtml?rev=1299993797&amp;do=diff</link>
        <description>Of these other technologies, the most obvious (and most simple) is Dynamic HTML, or DHTML. It is a technique, rather than a standard, for modifying the content of the web page and providing an application-like look and feel. Simply put, DHTML uses JavaScript to modify page elements dynamically. JavaScript functions modify either the styles or the HTML elements.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/dial?rev=1299651818&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:23:38-07:00</dc:date>
        <title>DIAL</title>
        <link>http://www.mobiledesign.org/dial?rev=1299651818&amp;do=diff</link>
        <description>Seeing a growing need to produce a standard means of markup for multiple contexts, the W3C has begun to develop a specification for a device-independent authoring language referred to as DIAL. DIAL is an XML language profile of XHTML2, shedding its SGML roots and becoming more of a means of delivering different content to different devices by using machine-readable constructs to define conditions.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/different_ia_for_different_devices?rev=1299980326&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:38:46-07:00</dc:date>
        <title>Different IA for Different Devices</title>
        <link>http://www.mobiledesign.org/different_ia_for_different_devices?rev=1299980326&amp;do=diff</link>
        <description>Depending on which devices you need to support, mobile wireframes can range from the very basic to the complex. On the higher-end devices with larger screens, we might be inclined to add more interactions, buttons, and other clutter to the screen, but this would be a mistake. Just because the user might have a more advanced phone, that doesn’t mean that he is giving you license to pack his screen with as much information as you can muster.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/do_nothing?rev=1299652307&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:31:47-07:00</dc:date>
        <title>Do Nothing</title>
        <link>http://www.mobiledesign.org/do_nothing?rev=1299652307&amp;do=diff</link>
        <description>Our first of four multiserving strategies is to simply do nothing, or rather to wait for the technology to adapt to our principles—which actually isn’t as foolish as it might sound.

In 2005, the W3C created the Mobile Web Initiative (MWI) to attempt to bring the standardization it achieved with the desktop web to mobile. This was a difficult challenge, because the W3C had not issued any specifications for mobile standards. The announcement of the effort included an introduction from Tim Berners…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/document_structure?rev=1299988396&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:53:16-07:00</dc:date>
        <title>Document Structure</title>
        <link>http://www.mobiledesign.org/document_structure?rev=1299988396&amp;do=diff</link>
        <description>The following are guidelines, recommendations, and best practices to structure your XHTML-MP documents appropriately. Different classes of browsers treat each of these best practices differently, so use the following list to determine how closely you should adhere to them:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/domain_folders?rev=1300040114&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:15:14-07:00</dc:date>
        <title>domain.com/mobile or domain.com/m</title>
        <link>http://www.mobiledesign.org/domain_folders?rev=1300040114&amp;do=diff</link>
        <description>Before subdomains were all the rage, most sites used a folder, such as domain.com/m. Although it’s not as common these days, I think this method works well when combined with subdomains to solve the problem with multiple mobile sites. For example, m.domain.com might point to your lowest-common-denominator site and m.domain.com/iphone would point to your iPhone site. Any additional versions you create later, such as m.domain.com/android/, might simply be added into folders on your m-domain. Using…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/don_t_convert_create?rev=1299651168&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:12:48-07:00</dc:date>
        <title>Don't Convert, Create</title>
        <link>http://www.mobiledesign.org/don_t_convert_create?rev=1299651168&amp;do=diff</link>
        <description>The question I am most frequently asked is “How do I convert my product to mobile?” and my answer is that you don’t. Simply porting a site, application, or game to the mobile medium is a big mistake. Although there is plenty that we can learn from products in other media, the mobile market is unique in its challenges and its benefits. The best place to begin a mobile strategy is by creating a product, not simply trying to reimagine one for small screens.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/dotmobi?rev=1300040189&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:16:29-07:00</dc:date>
        <title>domain.mobi</title>
        <link>http://www.mobiledesign.org/dotmobi?rev=1300040189&amp;do=diff</link>
        <description>The .mobi top-level domain is the ICANN-approved top-level domain specifically for mobile devices and gives publishers the option to use an alternate domain for their mobile site. Instead of using device detection, subdomains, or directors, mobile users go to domain.mobi.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/dotmobi_wordpress_mobile_pack?rev=1300039516&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:05:16-07:00</dc:date>
        <title>dotMobi WordPress Mobile Pack</title>
        <link>http://www.mobiledesign.org/dotmobi_wordpress_mobile_pack?rev=1300039516&amp;do=diff</link>
        <description>James Pearce and the folks at dotMobi have taken WordPress integration one step further, turning WordPress into a full-fledged mobile content management system. Their solution provides the following features:
XHTML

The dotMobi WordPress Mobile Pack is available for free.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/estimating_the_testing_effort?rev=1300042322&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:52:02-07:00</dc:date>
        <title>Estimating the Testing Effort</title>
        <link>http://www.mobiledesign.org/estimating_the_testing_effort?rev=1300042322&amp;do=diff</link>
        <description>FIG 15-2An example mobile project plan, showing how lengthy QA cycles can delay phases

One of the worst mistakes you can make is underestimating the time and resources required to test your work on multiple devices. The rule of thumb is that device testing can take anywhere between two and four times the development effort, meaning that for every developer, you need at least two to three QA resources. Or if you are flying solo, then for every week of development, you can easily spend two testin…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/example_device_plans?rev=1300041358&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:35:58-07:00</dc:date>
        <title>Example Device Plans</title>
        <link>http://www.mobiledesign.org/example_device_plans?rev=1300041358&amp;do=diff</link>
        <description>Creating a device plan is as simple as understanding profit and loss, assuming of course that you think understanding profit and loss is simple. Essentially, certain devices will cost more to develop and test for and certain devices will generate more traffic or downloads. Subtract the estimated cost from your estimated revenue and you have your estimated profit. Target the more profitable device class first.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/firefox?rev=1300043246&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:07:26-07:00</dc:date>
        <title>Firefox</title>
        <link>http://www.mobiledesign.org/firefox?rev=1300043246&amp;do=diff</link>
        <description>FIG 15-8Using the Firefox User Agent Switcher to test device detection methods

One challenge when using device detection techniques is making sure that they work! The Firefox User Agent Switcher extension lets you change the user agent information you send to the server (FIG 15-8). Once you add the data from the supported mobile user agents, you can test how each of your targeted sites renders for the requesting device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/five_assumptions_about_one_web?rev=1299652316&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:31:56-07:00</dc:date>
        <title>Five Assumptions About One Web</title>
        <link>http://www.mobiledesign.org/five_assumptions_about_one_web?rev=1299652316&amp;do=diff</link>
        <description>I’ll be honest: this approach can work really well when you design your content with it in mind, but it isn’t very flexible or robust, and it isn’t without flaws:


These five assumptions will go away in time. In fact, the iPhone and other modern mobile browsers have been designed specifically to address the first four assumptions, which is why Apple has described the iPhone as a “One Web” device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/fixed_footer?rev=1300035748&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:02:28-07:00</dc:date>
        <title>Fixed Footer</title>
        <link>http://www.mobiledesign.org/fixed_footer?rev=1300035748&amp;do=diff</link>
        <description>FIG 12-17An example of using CSS transforms to create a fixed footer

I mentioned earlier that one of the things the iPhone doesn’t support is the ability to display fixed position content at the bottom of the viewport, because you can scroll the entire viewport. This is incredibly annoying if you want to create a bottom tab bar, similar to the native app convention.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/focus_on_context_goals_and_needs?rev=1299651152&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:12:32-07:00</dc:date>
        <title>Focus on Context, Goals, and Needs</title>
        <link>http://www.mobiledesign.org/focus_on_context_goals_and_needs?rev=1299651152&amp;do=diff</link>
        <description>We already discussed context abstractly. By now you understand that context is crucial to creating any mobile product strategy, but how do you find it? When designing a mobile strategy, predicting the user’s context is very hard. It is a moment in time, with so many variables. We can mentally picture only so many circumstances that could impact the equation before our heads feel like they’re going to explode. It isn’t impossible, but it isn’t easy.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/font_and_text_properties?rev=1299989738&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:15:38-07:00</dc:date>
        <title>Font and Text Properties</title>
        <link>http://www.mobiledesign.org/font_and_text_properties?rev=1299989738&amp;do=diff</link>
        <description>The typography options on mobile devices can be less than stellar, but like most things CSS-related, we are seeing mobile browsers move closer to their desktop cousins in this respect. This section covers the font and text options for mobile devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/forget_what_you_think_you_know?rev=1299651124&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:12:04-07:00</dc:date>
        <title>Forget What You Think You Know</title>
        <link>http://www.mobiledesign.org/forget_what_you_think_you_know?rev=1299651124&amp;do=diff</link>
        <description>The first step is to set aside what you think you know. I’ve talked to several executives and even developers who are quick to explain that they ignore mobile because of this reason or that reason. Their reason is usually based on outdated or even incorrect information that is guiding their assumptions about the medium.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/forms?rev=1299989099&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:04:59-07:00</dc:date>
        <title>Forms</title>
        <link>http://www.mobiledesign.org/forms?rev=1299989099&amp;do=diff</link>
        <description>Designing and developing great forms can be a challenge in the mobile context. In the Class A browsers, forms can resemble their desktop cousins, but for all other browsers, forms don’t always render like you might expect. However, the larger challenge is actually for the user, as forms are difficult to control and add content to. The rule of thumb is to limit the use of forms in the mobile context.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/fragmentation?rev=1299651559&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:19-07:00</dc:date>
        <title>Fragmentation</title>
        <link>http://www.mobiledesign.org/fragmentation?rev=1299651559&amp;do=diff</link>
        <description>First of all, we already know that mobile is a much larger playing field than desktop computing, but there is currently no economically feasible means to create native applications that can support the majority of the market. There isn’t just a handful of platforms to contend with or a clear market leader, but literally hundreds (when you include all the variations), with no one vendor able to firmly claim itself king. Getting your application on one platform is a snap, but getting it on two is …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/frames?rev=1299651908&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:25:08-07:00</dc:date>
        <title>Frames</title>
        <link>http://www.mobiledesign.org/frames?rev=1299651908&amp;do=diff</link>
        <description>Frames just don’t work in mobile design. In most cases, either devices don’t support them or they cause a variety of usability problems. Instead, try applying server-side includes for loading local content.



TablesForms
Table of Contents




$16Download Now »$21Amazon.com »pinch/zoomLet's talkContact Us »</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/frames_testing?rev=1300042859&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:00:59-07:00</dc:date>
        <title>Frames</title>
        <link>http://www.mobiledesign.org/frames_testing?rev=1300042859&amp;do=diff</link>
        <description>Many web browsers have a minimum window size that is larger than your average device screen, making it impractical for testing mobile websites or web apps in a desktop browser. This is where inline framesets, or iframes, come in handy. Create a web page with an iframe, specifying the dimensions to match your target mobile screen (as shown in the following code), and then add the URL to your mobile project:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/full-screen_mode?rev=1300036853&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:20:53-07:00</dc:date>
        <title>Full-Screen Mode</title>
        <link>http://www.mobiledesign.org/full-screen_mode?rev=1300036853&amp;do=diff</link>
        <description>With Mobile Safari, it is possible to run a mobile web application in full-screen mode without the default Safari user interface, or “browser chrome.” This is useful for creating an immersive user experience, on par with a native application. Simply add the previous example line of code to the head of your document, and each time it is launched from the Home screen, it will load without the browser chrome (if launched within Safari, it will obviously have the browser chrome):</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/full_adaptation?rev=1299652470&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:34:30-07:00</dc:date>
        <title>Full Adaptation</title>
        <link>http://www.mobiledesign.org/full_adaptation?rev=1299652470&amp;do=diff</link>
        <description>The fourth and final multiserving strategy is _full content adaptation_, or the process of making extremely unique mobile experiences based on the device that is requesting the content—almost always dynamically. Like the other multiserving strategies, it starts with detecting the device that is requesting content and matching that to a valid user-agent string; then the system outputs markup, styles, and images generated exclusively for that device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/games?rev=1299964079&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:07:59-07:00</dc:date>
        <title>Games</title>
        <link>http://www.mobiledesign.org/games?rev=1299964079&amp;do=diff</link>
        <description>FIG_6-7An example game for the iPhone

The final mobile medium is games, the most popular of all media available to mobile devices. Technically games are really just native applications that use the similar platform SDKs to create immersive experiences (FIG 6-7). But I treat them differently from native applications for two reasons: they cannot be easily duplicated with web technologies, and porting them to multiple mobile platforms is a bit easier than typical platform-based applications.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/graphics?rev=1299985439&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:03:59-07:00</dc:date>
        <title>Graphics</title>
        <link>http://www.mobiledesign.org/graphics?rev=1299985439&amp;do=diff</link>
        <description>FIG 8-17Ribot’s Little Spender application uses graphics to define the experience

The final design element is graphics, or the images that are used to establish or aid a visual experience. Graphics can be used to supplement the look and feel, or as content displayed inline with the text.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/greg_mulmash_s_mobile_browser_detection?rev=1300039364&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:02:44-07:00</dc:date>
        <title>Greg Mulmash’s Mobile Browser Detection</title>
        <link>http://www.mobiledesign.org/greg_mulmash_s_mobile_browser_detection?rev=1300039364&amp;do=diff</link>
        <description>Greg’s script, also written in PHP, goes one step further. Like Andy’s script, it looks at the requesting user agent string and looks for data recognizable as a mobile device or browser. Using the WURFL database of 6,750 different mobile browser User Agent IDs, this script caught 94.34 percent of them.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/having_a_device_plan?rev=1300041173&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:32:53-07:00</dc:date>
        <title>Having a Device Plan</title>
        <link>http://www.mobiledesign.org/having_a_device_plan?rev=1300041173&amp;do=diff</link>
        <description>I’ve mentioned numerous times in this book how challenging it is to support multiple devices. This is a problem that shouldn’t exist, but it does, and it likely always will. One day in the future, mobile phone platforms will be more alike than they currently are, but by that time we will have many more “mobile” devices to contend with.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/home?rev=1301376605&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:30:05-07:00</dc:date>
        <title>Home</title>
        <link>http://www.mobiledesign.org/home?rev=1301376605&amp;do=diff</link>
        <description>&quot; “Brian has hit the mark with this title! Mobile development is about so much more than APIs and the latest models of phones—it is about making a difference in the way we live, work and play. Reading this book should be the first task in any new mobile development project. Period.”&quot;</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/htaccess-based_device_detection?rev=1300039421&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:03:41-07:00</dc:date>
        <title>htaccess-Based Device Detection</title>
        <link>http://www.mobiledesign.org/htaccess-based_device_detection?rev=1300039421&amp;do=diff</link>
        <description>Another option available to sites running on Apache-based web servers is to create an .htaccess file to perform a device lookup method similar to the previous solutions. .htaccess files are magic little files that allow you to do URL rewriting, redirection, and other handy tricks that help to provide a positive user experience.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/html5?rev=1299992312&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:58:32-07:00</dc:date>
        <title>HTML5</title>
        <link>http://www.mobiledesign.org/html5?rev=1299992312&amp;do=diff</link>
        <description>HTML5 is designed to be the successor to HTML4, as a transitional standard to XHTML 2.0. It stays fairly close in syntax to the HTML4 and XHTML 1.0 standards that we are accustomed to, but moves away from its SGML roots as being simply a means to mark up a document, and into a robust web application platform, including several new scripting APIs that allow for common interactive functions in today’s web applications.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/images_and_objects?rev=1299988947&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:02:27-07:00</dc:date>
        <title>Images and Objects</title>
        <link>http://www.mobiledesign.org/images_and_objects?rev=1299988947&amp;do=diff</link>
        <description>The desktop web is rich with a variety of embedded content; however, due to the hardware limitation of many devices, you cannot assume that all mobile devices have the same capabilities.

Image types

Nearly all mobile devices support the JPEG, GIF, and PNG formats. Both the 8-bit PNG and the 24-bit PNG with alpha transparency are supposed to be supported as of WAP 2.0, but some older devices may not support them, due to hardware limitations. Whenever possible, use PNGs, as they are the recommen…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/immersive_full-screen_applications?rev=1299966861&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:54:21-07:00</dc:date>
        <title>Immersive Full-Screen Applications</title>
        <link>http://www.mobiledesign.org/immersive_full-screen_applications?rev=1299966861&amp;do=diff</link>
        <description>FIG 6-12An example of an immersive application

The final application context is an immersive full-screen application, like a game, a media player, or possibly even a single-screen utility. These applications are meant to consume the user’s focus, often doing so by filling the entire screen (FIG 6-12), and leaving no trace of the device user interface to distract the user. Again, the majority of mobile engagement occurs when the user has idle periods of time; the immersive context is typical in …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/in_the_beginning?rev=1301376923&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:35:23-07:00</dc:date>
        <title>In the Beginning</title>
        <link>http://www.mobiledesign.org/in_the_beginning?rev=1301376923&amp;do=diff</link>
        <description>For those of us who are older—that is, over the age of 30—when we think of what a telephone is and try to picture it, we might think of the phone illustrated in FIG 1-1.

FIG 1-1

The telephone is undoubtedly one of the greatest inventions of mankind. It revolutionized communications, enabling us to reach across great distances and share thoughts, ideas, and dreams with our fellow man, making the world a much smaller place in the process. In fact, the telephone is probably one the most defining …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/information_applications?rev=1299966727&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:52:07-07:00</dc:date>
        <title>Information Applications</title>
        <link>http://www.mobiledesign.org/information_applications?rev=1299966727&amp;do=diff</link>
        <description>FIG 6-10An example informative application

The informative application is an application context in which the one and only goal is to provide information, like a news site, an online directory, a marketing site, or even a mobile commerce site, where the key task of the user is to read and understand and it is not necessary to interact (FIG 6-10). This isn’t to say that you cannot include calls to action in the informative context—in fact, you should, but they should be based around what you can…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/interpreting_design?rev=1299651422&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:17:02-07:00</dc:date>
        <title>Interpreting Design</title>
        <link>http://www.mobiledesign.org/interpreting_design?rev=1299651422&amp;do=diff</link>
        <description>Mobile design reminds me of a 25-year veteran graphic designer friend of mine. His days were spent creating print designs and advertisements, defining precisely what each design would be, down to the picas and points. His method of design meant creating a vision for how to communicate information or ideas in his head, and then duplicating that on the printed page. In his mind, it wasn’t right unless it was exactly like his original vision.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/invent_a_new_model?rev=1299652679&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:37:59-07:00</dc:date>
        <title>Invent a New Model</title>
        <link>http://www.mobiledesign.org/invent_a_new_model?rev=1299652679&amp;do=diff</link>
        <description>Although each of these models have worked for many in the past, I’m not satisfied. I believe there are many opportunities to monetize mobile content—specifically, the mobile web. We just haven’t thought of all the ways to do so yet. As you begin to explore the world of mobile, you will undoubtedly bring new ideass for how to make money in mobile.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/iphone_gui_psd?rev=1300037632&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:33:52-07:00</dc:date>
        <title>iPhone GUI PSD</title>
        <link>http://www.mobiledesign.org/iphone_gui_psd?rev=1300037632&amp;do=diff</link>
        <description>FIG 12-19iPhone GUI PSD

One problem that comes up with creating iPhone web apps is having to recreate the iPhone user interface in HTML and CSS. Even if you are creating your own look and feel, it is still helpful to see Apple’s user interface in detail to make your app feel at home on the iPhone. Luckily, the kind folks at Teehan+Lax have provided us with a layered Photoshop file, complete with all of the iPhone GUI elements (FIG 12-19) needed to create an iPhone-inspired web app, or to be use…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/iphone_web_apps?rev=1299652017&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:26:57-07:00</dc:date>
        <title>iPhone Web Apps</title>
        <link>http://www.mobiledesign.org/iphone_web_apps?rev=1299652017&amp;do=diff</link>
        <description>I’ve said it many times already: the iPhone was a game changer in the mobile ecosystem. A big part of that change is the impact that it had on the mobile web and specifically on mobile web applications. The iPhone provided people all over the world a glimpse of the future of mobile—that the mobile web didn’t have to be these ugly lists of text, that now we could create something unique and cool for mobile devices using the same techniques we use on the Web.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/iui?rev=1300037695&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:34:55-07:00</dc:date>
        <title>iUI</title>
        <link>http://www.mobiledesign.org/iui?rev=1300037695&amp;do=diff</link>
        <description>FIG 12-20iUI

Shortly after the iPhone was released, during the first iPhoneDevCamp, developer Joe Hewitt created an open source user interface library that mimics the appearance and interactions of the iPhone. Originally dubbed iphonenav, the project is now known as iUI (FIG 12-20), and is one of the more popular tools used for creating iPhone web apps.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/javascript-based_device_detection?rev=1299652422&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:33:42-07:00</dc:date>
        <title>JavaScript-Based Device Detection</title>
        <link>http://www.mobiledesign.org/javascript-based_device_detection?rev=1299652422&amp;do=diff</link>
        <description>Yet another way to detect higher-end devices that support JavaScript is to look up the user agent and redirect if the value is true. For example, if we wanted to detect iPhones or iPod touches, we might add the following to the initial page of our domain:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/javascript?rev=1299990669&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:31:09-07:00</dc:date>
        <title>JavaScript</title>
        <link>http://www.mobiledesign.org/javascript?rev=1299990669&amp;do=diff</link>
        <description>Last, but not least, we come to JavaScript: the last pillar of mobile web development. Unfortunately, JavaScript simply hasn’t been a priority in mobile browsers for many years, due to the hardware limitations of devices. I frankly consider myself lucky to be dealing with a device that has decent CSS support, and if I have devices that support a little bit of JavaScript as well, then I’m ecstatic.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/javascript_iphone?rev=1299652129&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:28:49-07:00</dc:date>
        <title>JavaScript</title>
        <link>http://www.mobiledesign.org/javascript_iphone?rev=1299652129&amp;do=diff</link>
        <description>The scripting language supported by all major browsers is JavaScript. In an unfortunate naming accident, JavaScript has often been mistakenly considered to be Java’s younger sibling, but this is far from the truth, as the two languages have completely different pedigrees. JavaScript shares much with Microsoft VBScript, but is more ubiquitous across browser platforms.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/javascript_is_the_next_frontier?rev=1299651729&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:09-07:00</dc:date>
        <title>Javascript Is the Next Frontier</title>
        <link>http://www.mobiledesign.org/javascript_is_the_next_frontier?rev=1299651729&amp;do=diff</link>
        <description>If you are going to provide mobile web applications, you have to have a mobile web browser that supports Ajax, or, as it is technically known, XMLHttpRequest. It makes a lot of those cool interactions in your web browser work via the capability to load content asynchronously into your browser view.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/jqtouch?rev=1300037759&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:35:59-07:00</dc:date>
        <title>jQTouch</title>
        <link>http://www.mobiledesign.org/jqtouch?rev=1300037759&amp;do=diff</link>
        <description>FIG 12-21jQTouch

Another interface library called jQTouch is designed to include other WebKit browsers based on the popular JavaScript framework jQuery (FIG 12-21). It was created by designer David Kaneda, out of the need for a lightweight skinnable interface library for more than just the iPhone.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/keep_it_simple?rev=1299651177&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:12:57-07:00</dc:date>
        <title>Keep It Simple</title>
        <link>http://www.mobiledesign.org/keep_it_simple?rev=1299651177&amp;do=diff</link>
        <description>And if there was only one rule that I could impart to you, something that would summarize all of the previous rules, it would be this one: keep it simple.

Mobile devices are simple, but not stupid. In other words, they are actually very intelligent computers, but people want to use them in a simple way. People don’t want you to offer all the features of your existing application or web app. They want simple features that address basic needs and nothing more. The user must deal with many constra…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/keeping_it_simple?rev=1299979244&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:20:44-07:00</dc:date>
        <title>Keeping It Simple</title>
        <link>http://www.mobiledesign.org/keeping_it_simple?rev=1299979244&amp;do=diff</link>
        <description>When thinking about your mobile information architecture, you want to keep it as simple as possible.

Support your defined goals

If something doesn’t support the defined goals, lose it. Go back to your user goals and needs, and identify the tasks that map to them. Find those needs and fill them.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/layering_multiple_stylesheets_for_multiple_devices?rev=1299652361&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:32:41-07:00</dc:date>
        <title>Layering Multiple Stylesheets for Multiple Devices</title>
        <link>http://www.mobiledesign.org/layering_multiple_stylesheets_for_multiple_devices?rev=1299652361&amp;do=diff</link>
        <description>We can use the media queries technique from our first strategy to target our Class A browsers:


&lt;link media=&quot;only screen and (max-device-width: 480px)&quot; rel=&quot;stylesheet&quot;
href=&quot;class-a.css&quot; type=&quot;text/css&quot; /&gt;


This stylesheet would contain our more advanced styling, like rounded corners, heavy use of image replacement, and other advanced styling techniques, and would only be loaded for browsers that support CSS3.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/layout?rev=1299983579&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:32:59-07:00</dc:date>
        <title>Layout</title>
        <link>http://www.mobiledesign.org/layout?rev=1299983579&amp;do=diff</link>
        <description>FIG 8-7Using a low-fidelity wireframe to define the layout design element before visual design begins

Layout is an important design element, because it is how the user will visually process the page, but the structural and visual components of layout often get merged together, creating confusion and making your design more difficult to produce.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/locale_context?rev=1299966658&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:50:58-07:00</dc:date>
        <title>Locale Context</title>
        <link>http://www.mobiledesign.org/locale_context?rev=1299966658&amp;do=diff</link>
        <description>FIG_6-9An example locale application

The locale context is a newer application type that is still being defined by the mobile community, but we are certainly seeing some clear patterns of how to create locale applications (FIG 6-9). As more location information is being published online, and more devices add GPS to pinpoint the user’s location, locale is becoming an excellent data point to pivot information around. For example, I can use location to display the cafés nearest to my current locat…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/look_and_feel?rev=1299983318&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:28:38-07:00</dc:date>
        <title>Look and Feel</title>
        <link>http://www.mobiledesign.org/look_and_feel?rev=1299983318&amp;do=diff</link>
        <description>The concept of “look and feel” is an odd one, being subjective and hard to define. Typically, look and feel is used to describe appearance, as in “I want a clean look and feel” or “I want a usable look and feel.” The problem is: as a mobile designer, what does it mean? And how is that different than messaging?</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/making_money_in_mobile?rev=1300040389&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:19:49-07:00</dc:date>
        <title>Making Money in Mobile</title>
        <link>http://www.mobiledesign.org/making_money_in_mobile?rev=1300040389&amp;do=diff</link>
        <description>FIG 14-1Where the money goes in the mobile industry

The mobile industry is worth an estimated one trillion dollars. Trillion-dollar figures get thrown around quite a bit these days, especially after the worldwide economic crisis of 2008 and 2009. But we forget how extremely large a trillion dollars is. To put it into perspective, a trillion dollars is 1,000×$1,000,000,000 (a billion) or 1,000,000×$1,000,000; certainly, it’s not chump change.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/markup?rev=1299651852&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:24:12-07:00</dc:date>
        <title>Markup</title>
        <link>http://www.mobiledesign.org/markup?rev=1299651852&amp;do=diff</link>
        <description>Markup is used to make content readable by mobile browsers. Normally when we think of markup, we think of HTML, or Hypertext Markup Language, the language of the Web. In mobile, we use slightly different markup languages, depending on the scope and size of your project or on your target devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/markup_iphone?rev=1299652068&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:27:48-07:00</dc:date>
        <title>Markup</title>
        <link>http://www.mobiledesign.org/markup_iphone?rev=1299652068&amp;do=diff</link>
        <description>WebKit is about as modern a browser as it gets, supporting nearly every approved web standard we have; the only other browser engine that comes close is the Trident browsing engine used in many of Opera’s browsers. The challenge with today’s browsers is for the first time, desktop browser makers are ahead of the W3C, implementing standards that are being discussed by the W3C working groups but not yet finalized. My hope would be that by the time you read this book, the specifications for HTML5 o…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/message?rev=1299983107&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:25:07-07:00</dc:date>
        <title>Message</title>
        <link>http://www.mobiledesign.org/message?rev=1299983107&amp;do=diff</link>
        <description>Another design element is your message, or what you are trying to say about your site or application visually. One might also call it the “branding,” although I see branding and messaging as two different things. Your message is the overall mental impression you create explicitly through visual design. I like to think of it as the holistic or at times instinctual reaction someone will have to your design. If you take a step back, and look at a design from a distance, what is your impression? Or …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobify?rev=1300039911&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:11:51-07:00</dc:date>
        <title>Mobify</title>
        <link>http://www.mobiledesign.org/mobify?rev=1300039911&amp;do=diff</link>
        <description>The folks at Mobify have taken this process of adaptation and made it available for anyone. Using Mobify’s web-based tool requires no setup or installation. You can simply point to the content from your desktop website and then apply styling to it. After you point your mobile domain to Mobify, you have an effortlessly adapted site that supports more than 4,000 devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_2.0?rev=1299651681&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:21-07:00</dc:date>
        <title>Mobile 2.0</title>
        <link>http://www.mobiledesign.org/mobile_2.0?rev=1299651681&amp;do=diff</link>
        <description>You’ve probably heard the term “Web 2.0.” Although it’s a commonly used term, most people you ask in the web business can’t tell you what it means. To put it simply, it is just a label for the second generation of the web industry. But more importantly, it is meant to denote a change in that what we now believe in and stand for, which is not as it was before. The suffix 2.0 in technology implies that a product is new and improved, reinvented to be better and maybe even more relevant.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_application_media_matrix?rev=1299964147&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:09:07-07:00</dc:date>
        <title>Mobile Application Media Matrix</title>
        <link>http://www.mobiledesign.org/mobile_application_media_matrix?rev=1299964147&amp;do=diff</link>
        <description>In summary, to aid in comparing and contrasting which of these mobile application media is best for your mobile product, I’ve placed them into a matrix (TABLE 6-1).

TABLE 6-1

Mobile application media matrix

 Device supportComplexityUser experienceLanguageOffline supportDevice featuresSMSAllSimpleLimitedN/ANoNoneMobile websitesAllSimpleLimitedHTMLNoNoneMobile web widgetsSomeMediumGreatHTMLLimitedLimitedMobile web applicationsSomeMediumGreatHTML, CSS, JavaScriptLimitedLimitedNative applications…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_application_medium_types?rev=1299962327&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:38:47-07:00</dc:date>
        <title>Mobile Application Medium Types</title>
        <link>http://www.mobiledesign.org/mobile_application_medium_types?rev=1299962327&amp;do=diff</link>
        <description>FIG 6-1

The mobile medium type is the type of application framework or mobile technology that presents content or information to the user. It is a technical approach regarding which type of medium to use; this decision is determined by the impact it will have on the user experience. The technical capabilities and capacity of the publisher also factor into which approach to take.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_as_a_medium?rev=1299915945&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:45:45-07:00</dc:date>
        <title>Mobile As a Medium</title>
        <link>http://www.mobiledesign.org/mobile_as_a_medium?rev=1299915945&amp;do=diff</link>
        <description>After examining the size and scope of the mobile market, you need to understand what it means to your users and ultimately how it will benefit the business.

One of the best introductions I’ve ever heard was from Tomi Ahonen, an author and expert on next-generation wireless, who describes mobile as “the seventh mass media.” He points out that each of the mass media we use every day has advantages and disadvantages, each playing a significant role in society, with mobile being the latest in the s…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_design?rev=1299982422&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:13:42-07:00</dc:date>
        <title>Mobile Design</title>
        <link>http://www.mobiledesign.org/mobile_design?rev=1299982422&amp;do=diff</link>
        <description>FIG 8-1A lowest-common-denominator design

When building mobile experiences, it is impossible to create a great experience without three ingredients: context, information architecture, and visual design. This chapter focuses on the latter ingredient of the recipe. The visual design of your experience is the direct representation of everything underneath; it is the first impression the user will have. A great design gives the user high expectations of your site or application; a poor design leads…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_design_tent-pole?rev=1299982835&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:20:35-07:00</dc:date>
        <title>Mobile Design Tent-Pole</title>
        <link>http://www.mobiledesign.org/mobile_design_tent-pole?rev=1299982835&amp;do=diff</link>
        <description>FIG 8-2The app icon design greatly influences the user’s expectation of quality

In Hollywood, executives like to use the term “tent-pole” to describe their movies and television shows. The term has dual meanings: one is business, and the other creative. The business goal of a tent-pole production is to support or prop up the losses from other productions. However, to create a tent-pole production, the creators involved must make an artistic work that they know will appeal to the largest possibl…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_design_tools?rev=1299985474&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:04:34-07:00</dc:date>
        <title>Mobile Design Tools</title>
        <link>http://www.mobiledesign.org/mobile_design_tools?rev=1299985474&amp;do=diff</link>
        <description>As I mentioned earlier, mobile design requires understanding the design elements and specific tools. The closest thing to a common design tool is Adobe Photoshop, though each framework has a different method of implementing the design into the application. Some frameworks provide a complete interface toolkit, allowing designers or developers to simply piece together the interface, while others leave it to the designer to define from scratch.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_fu?rev=1300039545&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:05:45-07:00</dc:date>
        <title>Mobile Fu</title>
        <link>http://www.mobiledesign.org/mobile_fu?rev=1300039545&amp;do=diff</link>
        <description>Moving away from PHP-based solutions, Mobile Fu is a free plugin for Ruby on Rails. It will automatically detect mobile devices that access your Rails application, then dynamically define the stylesheet to be viewed depending on the requesting device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_ia?rev=1299979169&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:19:29-07:00</dc:date>
        <title>Mobile IA</title>
        <link>http://www.mobiledesign.org/mobile_ia?rev=1299979169&amp;do=diff</link>
        <description>FIG 7-2Comparing the New York Times website in desktop and mobile browsers

Although information architecture has become a common discipline in the web industry, unfortunately, the mobile industry—like software—has only a handful of specialized mobile information architects. Although mobile information architecture is hardly a discipline in its own right, it certainly ought to be. This is not because it is so dissimilar from its desktop cousin, but because of context, added technical constraints…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_information_architecture?rev=1299973119&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T15:38:39-07:00</dc:date>
        <title>Mobile Information Architecture</title>
        <link>http://www.mobiledesign.org/mobile_information_architecture?rev=1299973119&amp;do=diff</link>
        <description>Your information architecture (also known as IA), is the foundation of your mobile product. A well-engineered product with good visual design can still fail because of poor information architecture. The truly successful mobile products always have a well-thought-out information architecture.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_needs_to_check_its_ego?rev=1299651768&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:48-07:00</dc:date>
        <title>Mobile Needs to Check Its Ego</title>
        <link>http://www.mobiledesign.org/mobile_needs_to_check_its_ego?rev=1299651768&amp;do=diff</link>
        <description>For years, I’ve sat on the line between the mobile community and the web community. They have treated each other almost like rivals. I’ve been frustrated with both sides, but it is the mobile camp that needs to check their egos at the door and get into the game, before they learn that all the rules have changed.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_usability_test_tips_and_tricks?rev=1299652834&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:40:34-07:00</dc:date>
        <title>Mobile Usability Test Tips and Tricks</title>
        <link>http://www.mobiledesign.org/mobile_usability_test_tips_and_tricks?rev=1299652834&amp;do=diff</link>
        <description>Conducting a great mobile usability test comes down to being prepared, keeping context in mind, and being casual and comfortable with the participants. Here are a few tips and tricks that I have found to work well:



Supporting devices, from device plans to usability tests, can certainly be a challenge, but it doesn’t have to be. Be prepared, be smart about your plan, and after a few projects, you’ll have it down pat.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_web_applications?rev=1299963867&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:04:27-07:00</dc:date>
        <title>Mobile Web Applications</title>
        <link>http://www.mobiledesign.org/mobile_web_applications?rev=1299963867&amp;do=diff</link>
        <description>FIG 6-5The Facebook mobile web app

Mobile web applications are mobile applications that do not need to be installed or compiled on the target device. Using XHTML, CSS, and JavaScript, they are able to provide an application-like experience to the end user while running in any mobile web browser. By “application-like” experience, I mean that they do not use the drill-down or page metaphors in which a click equals a refresh of the content in view. Web applications allow users to interact with con…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_web_applications_are_the_future?rev=1299651720&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:00-07:00</dc:date>
        <title>Mobile Web Applications Are the Future</title>
        <link>http://www.mobiledesign.org/mobile_web_applications_are_the_future?rev=1299651720&amp;do=diff</link>
        <description>Creating mobile web applications instead of mobile software applications has remained an area of significant motivation and interest. The mobile community is looking at the Web 2.0 revolution for inspiration, being able to create products and get them to market quickly and at little cost. They see the success of small iterative development cycles and want to apply this to mobile development, something that is not that feasible in the traditional mobile ecosystem.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_web_apps_versus_native_applications?rev=1299651543&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:03-07:00</dc:date>
        <title>Mobile Web Apps Versus Native Applications</title>
        <link>http://www.mobiledesign.org/mobile_web_apps_versus_native_applications?rev=1299651543&amp;do=diff</link>
        <description>When should you make a mobile web application versus a native mobile application, or a downloadable application designed for a specific platform, like a Java application or an iPhone? It wasn’t that long ago that people didn’t even bother asking the question; every mobile application was native.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_web_development?rev=1299987354&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:35:54-07:00</dc:date>
        <title>Mobile Web Development</title>
        <link>http://www.mobiledesign.org/mobile_web_development?rev=1299987354&amp;do=diff</link>
        <description>In this chapter, I discuss the foundational principles and techniques for creating designs for multiple mobile devices. As discussed earlier, the mobile web is the only ubiquitous platform for delivering content to mobile devices. This makes it an incredibly powerful platform in terms of its reach, but like most things in mobile, every blessing comes with a curse. The price for ubiquity is that not all designs are rendered the same.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_web_widgets?rev=1299963742&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:02:22-07:00</dc:date>
        <title>Mobile Web Widgets</title>
        <link>http://www.mobiledesign.org/mobile_web_widgets?rev=1299963742&amp;do=diff</link>
        <description>FIG 6-4An example mobile web widget

Largely in response to the poor experience provided by the mobile web over the years, there has been a growing movement to establish mobile widget frameworks and platforms. For years the mobile web user experience was severely underutilized and failed to gain traction in the market, so several operators, device makers, and publishers began creating widget platforms (FIG 6-4) to counter the mobile web’s weaknesses.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_websites?rev=1299963575&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:59:35-07:00</dc:date>
        <title>Mobile Websites</title>
        <link>http://www.mobiledesign.org/mobile_websites?rev=1299963575&amp;do=diff</link>
        <description>FIG 6-3An example of a mobile website

As you might expect, a mobile website is a website designed specifically for mobile devices, not to be confused with viewing a site made for desktop browsers on a mobile browser. Mobile websites are characterized by their simple “drill-down” architecture, or the simple presentation of navigation links that take you to a page a level deeper, as shown in FIG 6-3.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobile_widgets_are_the_next_big_thing?rev=1299651752&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:32-07:00</dc:date>
        <title>Mobile Widgets Are the Next Big Thing</title>
        <link>http://www.mobiledesign.org/mobile_widgets_are_the_next_big_thing?rev=1299651752&amp;do=diff</link>
        <description>At many Mobile 2.0 events, I’ve heard a lot of buzz about mobile widgets, though no one can tell me how mobile widgets would define a mobile widget, or how they are different from mobile web apps. The consensus seems to be that the solution for the challenges with the mobile web is to create a series of “small webs” targeted at a specific user or task. Though I couldn’t figure out the problem being solved with these widgets, I had to admit that they looked pretty cool.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/mobileaware?rev=1300039988&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:13:08-07:00</dc:date>
        <title>MobileAware</title>
        <link>http://www.mobiledesign.org/mobileaware?rev=1300039988&amp;do=diff</link>
        <description>FIG 13-6The MobileAware web service

MobileAware is an enterprise mobile adaptation system. Like the others, it can detect, adapt, and deliver experiences based on the requesting device (FIG 13-6).

It is available for Java-based servers for a fee. More information is available at &lt;http://www.mobileaware.com&gt;.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/multitouch?rev=1300035485&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T09:58:05-07:00</dc:date>
        <title>Multitouch</title>
        <link>http://www.mobiledesign.org/multitouch?rev=1300035485&amp;do=diff</link>
        <description>FIG 12-16An example of multitouch on the iPhone

The iPhone, as of OS 2.0, includes the ability to recognize and handle both multitouch events as well as gestures. This effectively provides Mobile Safari with many of the same user interface abilities that you might find in the native API. Unfortunately, not much attention has been paid to the addition of multitouch, being overshadowed by the iPhone API.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/native_applications?rev=1299963973&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:06:13-07:00</dc:date>
        <title>Native Applications</title>
        <link>http://www.mobiledesign.org/native_applications?rev=1299963973&amp;do=diff</link>
        <description>FIG 6-6A native application in the iPhone

The next mobile application medium is the oldest and the most common; it is referred to as native applications, which is actually a misnomer because a mobile web app or mobile web widget can target the native features of the device as well. These applications actually should be called “platform applications,” as they have to be developed and compiled for each mobile platform.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/netbiscuits?rev=1300039901&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:11:41-07:00</dc:date>
        <title>Netbiscuits</title>
        <link>http://www.mobiledesign.org/netbiscuits?rev=1300039901&amp;do=diff</link>
        <description>FIG 13-5The Netbiscuits web service

Netbiscuits is a web service, like the others, that allows you to create and manage mobile websites and web applications and then detect, adapt, and deliver the experiences to the right devices (FIG 13-5).

It is available in JSP, PHP, and .NET as both a hosted and a custom API in different pricing tiers. Read more about Netbiscuits at &lt;http://www.netbiscuits.com&gt;.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/networks?rev=1299913378&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:02:58-07:00</dc:date>
        <title>Networks</title>
        <link>http://www.mobiledesign.org/networks?rev=1299913378&amp;do=diff</link>
        <description>Operators operate wireless networks. Remember that cellular technology is just a radio that receives a signal from an antenna. The type of radio and antenna determines the capability of the network and the services you can enable on it.

You’ll notice that the vast majority of networks around the world use the GSM standard (see TABLE 2-2 for an explanation of these acronyms), using GPRS or GPRS EDGE for 2G data and UMTS or HSDPA for 3G. We also have CDMA (Code Division Multiple Access) and its 2…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/new_rules?rev=1299960948&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:15:48-07:00</dc:date>
        <title>New Rules</title>
        <link>http://www.mobiledesign.org/new_rules?rev=1299960948&amp;do=diff</link>
        <description>Mobile is a different medium and is governed by a different set of rules. Great mobile products are able to adapt or even look beyond traditional strategy to identify new and unique ways to address both the challenges and the benefits that the mobile medium has to offer.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/offline_users?rev=1299651662&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:02-07:00</dc:date>
        <title>Offline Users</title>
        <link>http://www.mobiledesign.org/offline_users?rev=1299651662&amp;do=diff</link>
        <description>The final reason to make a native application is because you know the user is likely to be offline or out of range of a mobile network. For those of us who live in the city, that may seem like a rare occasion. Even for those who live in more rural areas, network dead spots are becoming increasingly rare. But going periods without a connection does of course happen frequently and your application should be designed to take this into account.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/opera?rev=1300042959&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:02:39-07:00</dc:date>
        <title>Opera</title>
        <link>http://www.mobiledesign.org/opera?rev=1300042959&amp;do=diff</link>
        <description>FIG 15-5Desktop testing using Opera’s Small Screen view

The Opera desktop browser has a Small Screen view (see FIG 15-5) that mimics a mobile screen, loading the handheld media type if available and presenting the page in a narrower format. Because Opera uses the same rendering engine for its desktop browser as the Opera Mobile product, what appears on one is likely to appear the same on the other. However, Opera Mini, the more popular of the two Opera browsers, uses a different rendering engin…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/operating_systems?rev=1299914165&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:16:05-07:00</dc:date>
        <title>Operating Systems</title>
        <link>http://www.mobiledesign.org/operating_systems?rev=1299914165&amp;do=diff</link>
        <description>It used to be that if a mobile device ran an operating system, it was most likely considered a smartphone. But as technology gets smaller, a broader set of devices supports operating systems.

Operating systems often have core services or toolkits that enable applications to talk to each other and share data or services. Mobile devices without operating systems typically run “walled” applications that do not talk to anything else.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/operators?rev=1299913403&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:03:23-07:00</dc:date>
        <title>Operators</title>
        <link>http://www.mobiledesign.org/operators?rev=1299913403&amp;do=diff</link>
        <description>The base layer in the mobile ecosystem is the operator. Operators go by many names, depending on what part of the world you happen to be in or who you are talking to. Operators can be referred to as Mobile Network Operators (MNOs); mobile service providers, wireless carriers, or simply carriers; mobile phone operators; or cellular companies. In the mobile community, we officially refer to them as operators, though in the United States, there is a tendency to call them carriers.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/other_recommendations?rev=1299989134&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:05:34-07:00</dc:date>
        <title>Other Recommendations</title>
        <link>http://www.mobiledesign.org/other_recommendations?rev=1299989134&amp;do=diff</link>
        <description>But wait—there’s more! Here are just a few more best practices specific to mobile devices.

Validate markup

Nonvalidating markup may not display correctly or efficiently on mobile devices. In some cases, especially on older phones, nonvalidating XHTML-MP won’t render at all, leaving users with an error message in their browser. Using the W3C validator can be helpful for finding rendering errors.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/phonegap?rev=1300037548&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:32:28-07:00</dc:date>
        <title>PhoneGap</title>
        <link>http://www.mobiledesign.org/phonegap?rev=1300037548&amp;do=diff</link>
        <description>FIG 12-18A PhoneGap project

A great tool for building native apps from web apps is PhoneGap (&lt;http://www.phonegap.com&gt;), an open source library that enables you to take a mobile web app and compile it into a native app for the iPhone, Android, BlackBerry, and other platforms. You can simply download the PhoneGap code, then open the project in the appropriate framework development environment; for example, to create an iPhone application, open up the phonegap.xcode project in Apple’s Xcode (FIG …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/platforms?rev=1299913901&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:11:41-07:00</dc:date>
        <title>Platforms</title>
        <link>http://www.mobiledesign.org/platforms?rev=1299913901&amp;do=diff</link>
        <description>A mobile platform’s primary duty is to provide access to the devices. To run software and services on each of these devices, you need a platform, or a core programming language in which all of your software is written. Like all software platforms, these are split into three categories: licensed, proprietary, and open source.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/positioning_and_page_flow?rev=1299990583&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:29:43-07:00</dc:date>
        <title>Positioning and Page Flow</title>
        <link>http://www.mobiledesign.org/positioning_and_page_flow?rev=1299990583&amp;do=diff</link>
        <description>CSS goes beyond just being able to add design content within the page; it can also be used to define the design layout of the page. Using positioning and page flow attributes, we can add style to the page and help make it easier to read or interact with on small screens.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/preface?rev=1300048283&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T13:31:23-07:00</dc:date>
        <title>Preface</title>
        <link>http://www.mobiledesign.org/preface?rev=1300048283&amp;do=diff</link>
        <description>I’ll be honest: I’m an introduction-skipper. When I sit down with a technical book, I skip right past the introduction or preface and go straight for the goods. If it doesn’t begin with the words “Chapter,” then I figure I can probably move on and not miss anything crucial. This is not, however, one of those books.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/productivity_applications?rev=1299966794&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:53:14-07:00</dc:date>
        <title>Productivity Applications</title>
        <link>http://www.mobiledesign.org/productivity_applications?rev=1299966794&amp;do=diff</link>
        <description>FIG 6-11An example productivity application

The productivity application context is used for content and services that are heavily task-based and meant to increase the users’ sense of efficiency. With these types of applications, we can assume that the users are more committed to accomplishing a particular goal, like managing content such as messages, contacts, or media, but we should still assume that they are doing so during idle periods (FIG 6-11). Just because the application context is mea…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/progressive_enhancement?rev=1300039058&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:57:38-07:00</dc:date>
        <title>Progressive Enhancement</title>
        <link>http://www.mobiledesign.org/progressive_enhancement?rev=1300039058&amp;do=diff</link>
        <description>FIG 13-3Using a progressive enhancement technique to establish several fallbacks to our presentation

In Chapter 11, I talked about the concept of progressive enhancement, or the technique of using web techniques in a layered fashion to allow anyone with any web browser to access your content, regardless of the browser’s capabilities. This is actually our second multiserving strategy.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/progressive_enhancement_overview?rev=1299987765&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:42:45-07:00</dc:date>
        <title>Progressive Enhancement</title>
        <link>http://www.mobiledesign.org/progressive_enhancement_overview?rev=1299987765&amp;do=diff</link>
        <description>FIG 11-1Using progressive enhancement to layer support

Progressive enhancement is the practice of using web techniques in a layered fashion to allow anyone with any web browser to access your content, regardless of its capabilities. This means that you are creating not just one ideal experience, but multiple less-ideal experiences, depending on who views the content, also called graceful degradation. To illustrate this, take a look at FIG 11-1.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/promo?rev=1300047796&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T13:23:16-07:00</dc:date>
        <title>promo</title>
        <link>http://www.mobiledesign.org/promo?rev=1300047796&amp;do=diff</link>
        <description>$16Download Now »$21Amazon.com »pinch/zoomLet's talkContact Us »</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/prototyping?rev=1299980352&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:39:12-07:00</dc:date>
        <title>Prototyping</title>
        <link>http://www.mobiledesign.org/prototyping?rev=1299980352&amp;do=diff</link>
        <description>FIG 7-11A paper prototype, where the interaction is nothing more than drawings on note cards

As mentioned before, wireframes lack the capability to communicate more complex, often in-place, interactions of mobile experiences. This is where prototypes come in. Prototypes might sound like a scary (or costly) step in the process. Some view them as redundant or too time-consuming, preferring to jump in and start coding things. But as with wireframes, I’ve found that each product we’ve built out som…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/remote_access?rev=1300044494&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:28:14-07:00</dc:date>
        <title>Remote Access</title>
        <link>http://www.mobiledesign.org/remote_access?rev=1300044494&amp;do=diff</link>
        <description>FIG 15-12DeviceAnywhere

Remote access services let you remotely control an actual device through your desktop, but few exist; DeviceAnywhere is one. The application taps into the actual device, which you rent through the company’s software, and it has most of the devices sold in North America and Europe (FIG 15-12).</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/reverse_device_detection?rev=1300039455&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:04:15-07:00</dc:date>
        <title>Reverse Device Detection</title>
        <link>http://www.mobiledesign.org/reverse_device_detection?rev=1300039455&amp;do=diff</link>
        <description>I suggested an alternative approach to the problem in an article I wrote several years ago; I call this alternative reverse device detection. In this technique, the primary content on your domain is your basic or lowest-common-denominator mobile content. This ensures that basic devices, such as low-end mobile devices, eBook readers, or other basic mobile devices, still have a usable experience.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/rich_interactions_kill_battery_life?rev=1299651736&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:16-07:00</dc:date>
        <title>Rich interactions kill battery life</title>
        <link>http://www.mobiledesign.org/rich_interactions_kill_battery_life?rev=1299651736&amp;do=diff</link>
        <description>JavaScript and Ajax have been ignored because using an Ajax-based web application on your phone can drain your battery at a rate of four to five times your normal power consumption. I’ve heard a number of reasons for why this happens from mobile hardware guys much smarter than myself, but to summarize, the two most prevalent are:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/selectors?rev=1299989558&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:12:38-07:00</dc:date>
        <title>Selectors</title>
        <link>http://www.mobiledesign.org/selectors?rev=1299989558&amp;do=diff</link>
        <description>The selector is used to tell which markup elements it should apply rules to—basically, what makes CSS work to control the presentation. There are a number of different types of selectors:

Universal selector

The universal selector selects all elements useful for defining the default typeface or font size. body or html can be used as well:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/services?rev=1299650992&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:09:52-07:00</dc:date>
        <title>Services</title>
        <link>http://www.mobiledesign.org/services?rev=1299650992&amp;do=diff</link>
        <description>Finally, we come to the last layer in the mobile ecosystem: services. Services include tasks such as accessing the Internet, sending a text message, or being able to get a location—basically, anything the user is trying to do.

What makes the mobile environment such a complicated space to design and develop for are these layers, which the user must wade through in order to accomplish a simple task like “I want to send a text message,” “I want to get on the Web,” and “I want to access Google.” Th…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/simulators_and_emulators?rev=1300043587&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:13:07-07:00</dc:date>
        <title>Simulators and Emulators</title>
        <link>http://www.mobiledesign.org/simulators_and_emulators?rev=1300043587&amp;do=diff</link>
        <description>FIG 15-10The dotMobi emulator

Almost every mobile framework comes with an emulator (FIG 15-10) that allows you to test your work in a virtual environment. Because the hardware in your computer is different than the hardware on the device, it has to run in an emulated environment, and can therefore cause inconsistencies between the emulated environment and the real environment.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/site_maps?rev=1299979538&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:25:38-07:00</dc:date>
        <title>Site Maps</title>
        <link>http://www.mobiledesign.org/site_maps?rev=1299979538&amp;do=diff</link>
        <description>FIG 7-4An example mobile site map

The first deliverable we use to define mobile information architecture is the site map. Site maps are a classic information architecture deliverable. They visually represent the relationship of content to other content and provide a map for how the user will travel through the informational space, as shown in FIG 7-4.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/size_and_scope_of_the_mobile_market?rev=1299915722&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T23:42:02-07:00</dc:date>
        <title>Size and Scope of the Mobile Market</title>
        <link>http://www.mobiledesign.org/size_and_scope_of_the_mobile_market?rev=1299915722&amp;do=diff</link>
        <description>FIG 3-1

The earth’s population is a little over 6 billion. To break it down, in FIG 3-1 you can see the sizes of various countries around the world.

The United States of America has a population of 303 million people. The European Union’s population is 495 million. India’s is 1.2 billion. China’s is 1.3 billion, roughly one-fifth the population of the planet. If you compare these numbers to the number of mobile devices in FIG 3-2 you see some startling numbers.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/sms?rev=1299963381&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:56:21-07:00</dc:date>
        <title>SMS</title>
        <link>http://www.mobiledesign.org/sms?rev=1299963381&amp;do=diff</link>
        <description>FIG 6-2An SMS application to interact with a billboard in Manhattan

The most basic mobile application you can create is an SMS application. Although it might seem odd to consider text messages applications, they are nonetheless a designed experience. Given the ubiquity of devices that support SMS, these applications can be useful tools when integrated with other mobile application types.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/subdomains?rev=1300040032&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:13:52-07:00</dc:date>
        <title>m.domain.com</title>
        <link>http://www.mobiledesign.org/subdomains?rev=1300040032&amp;do=diff</link>
        <description>The most common method is to prefix your site domain with a subdomain called “m”—for example, m.your-domain-name.com. Now that many sites are providing normal and iPhone versions of their sites, we have m.domain.com and iphone.domain.com. It’s hardly consistent or the best experience for the user, but it is extremely simple to set up.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/supporting_devices?rev=1299652687&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:38:07-07:00</dc:date>
        <title>Supporting Devices</title>
        <link>http://www.mobiledesign.org/supporting_devices?rev=1299652687&amp;do=diff</link>
        <description>Imagine a restaurant where you could just walk up and order whatever you felt like—no menu, just anything you want. If you felt like eating a salad, the restaurant would make you a salad. If you felt like a steak, it would make you steak just the way you liked it. If you wanted a banana, peanut butter, and potato chip sandwich, it would make it. Or, if you felt like ratatouille niçoise, in which each ingredient is sautéed separately, layered together, then baked to perfection (the proper way to …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/tables?rev=1299988999&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:03:19-07:00</dc:date>
        <title>Tables</title>
        <link>http://www.mobiledesign.org/tables?rev=1299988999&amp;do=diff</link>
        <description>Before I get to how you should use tables in mobile content, I’m going to let you in on another dirty little secret of the mobile web: the best way to get a consistent layout across multiple mobile browsers has been and still is to use copious amounts of nested layout tables. Like in the days before web standard techniques on the desktop, tables provide the best way to ensure that web designs render consistency across multiple browsers.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/taking_next_steps?rev=1299960847&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T12:14:07-07:00</dc:date>
        <title>Taking Next Steps</title>
        <link>http://www.mobiledesign.org/taking_next_steps?rev=1299960847&amp;do=diff</link>
        <description>Wow, that was a little painful, but at least I made my mother proud. All right, let’s put all the head-shrinking behind us and get to the practical stuff. The reason to dive into all this big C/little c nonsense is to illustrate that what has meaning to the user and what has meaning to us as the creators of experiences is different in terms of context. Can you guess which one is which?</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/taking_the_next_step?rev=1299652591&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:36:31-07:00</dc:date>
        <title>Taking the Next Step</title>
        <link>http://www.mobiledesign.org/taking_the_next_step?rev=1299652591&amp;do=diff</link>
        <description>How do you feel about adapting to mobile devices now? I hope that I was able to report the available options with a minimum of propaganda. Like I said at the beginning: there are no right or wrong answers, only what makes the most sense for your users.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/text_elements?rev=1299988745&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:59:05-07:00</dc:date>
        <title>Text Elements</title>
        <link>http://www.mobiledesign.org/text_elements?rev=1299988745&amp;do=diff</link>
        <description>If you are familiar with XHTML, then none of the following should be any revelation, but for good measure I want to make sure that each of the common text elements used in an XHTML document are included, and to describe how they can differ when rendered on a mobile device.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_brick_era?rev=1299967910&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T14:11:50-07:00</dc:date>
        <title>The Brick Era</title>
        <link>http://www.mobiledesign.org/the_brick_era?rev=1299967910&amp;do=diff</link>
        <description>FIG 1-3The Motorola DynaTAC 8000X was the first mobile phone to receive FCC acceptance, in 1983; DynaTAC was actually an abbreviation of Dynamic Adaptive Total Area Coverage

The first era I call the Brick Era (1973–1988). My first taste of mobile telephony was with my father’s suitcase phone that he purchased when I was still in school—basically a corded receiver connected to a portable radio the size (and weight) of a car battery. My father, never one to throw away a good piece of electronics,…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_candy_bar_era?rev=1301377009&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:36:49-07:00</dc:date>
        <title>The Candy Bar Era</title>
        <link>http://www.mobiledesign.org/the_candy_bar_era?rev=1301377009&amp;do=diff</link>
        <description>FIG 1-4

The second era, the Candy Bar Era (1988–1998), represented one of the more significant leaps in mobile technology. “Candy bar” is the actual term used to describe the long, thin, rectangular form factor of the majority of mobile devices used during the Candy Bar Era and even today (see FIG 1-4). At this point, network operators started to see the clear value (and big profits) in their burgeoning cellular networks, and a “perfect storm” ensued. The network shifted to second-generation (2…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_convergence_of_the_web_and_mobile?rev=1299651704&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:44-07:00</dc:date>
        <title>The Convergence of the Web and Mobile</title>
        <link>http://www.mobiledesign.org/the_convergence_of_the_web_and_mobile?rev=1299651704&amp;do=diff</link>
        <description>It is obvious that in the minds of many, Mobile 2.0 is the Web. At this point, the mobile web has always been viewed as a second-class citizen within the mobile ecosystem, for many reasons, as discussed later.

Mobile is already a medium, but the consensus is that by leveraging the power of the Web, integrating web services into the mobile medium is the future of mobile development. When the iPhone exploded onto the scene, it increased the usage of the mobile web by its users to levels never see…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_deck?rev=1300040720&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:25:20-07:00</dc:date>
        <title>The Deck</title>
        <link>http://www.mobiledesign.org/the_deck?rev=1300040720&amp;do=diff</link>
        <description>FIG 14-2The Vodafone deck

For nonsmartphone devices, it all starts with the operator portal, also referred to as the deck, which is the default site that is loaded when a mobile web browser is started (see FIG 14-2). It is analogous to the start page or home page that you see when you launch a web browser, but it is provided by your operator. The origin of this term comes from Hypercard and from the later WML development used to create mobile portals. Both languages use the “card” metaphor to d…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_design_myth?rev=1299982325&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:12:05-07:00</dc:date>
        <title>The Design Myth</title>
        <link>http://www.mobiledesign.org/the_design_myth?rev=1299982325&amp;do=diff</link>
        <description>FIG 7-15Comparing visual design to information design of the iPhone application Tweetie

A little secret about interactive design is that people don’t respond to the visual aesthetic as much as you might think. What colors you use, whether you use square or rounded corners, or, gradients or flat backgrounds, helps build first impressions, but it doesn’t do too much to improve the user’s experience. Don’t get me wrong: users appreciate good design, but they are quickly indifferent about the visua…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_device_detection_dilemma?rev=1299652378&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:32:58-07:00</dc:date>
        <title>The Device Detection Dilemma</title>
        <link>http://www.mobiledesign.org/the_device_detection_dilemma?rev=1299652378&amp;do=diff</link>
        <description>Device detection has been a technical challenge for many years. Although it’s hardly a challenge to those experienced in mobile development, I feel that the mobile community severely underappreciates how much of a challenge this is for the rest of us.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_device_matrix?rev=1299987923&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:45:23-07:00</dc:date>
        <title>The Device Matrix</title>
        <link>http://www.mobiledesign.org/the_device_matrix?rev=1299987923&amp;do=diff</link>
        <description>TABLE 11-1 provides a listing of popular browsers and their assigned classes, starting with A, the highest grade, to be considered on par with desktop browsers, and ending with F, the lowest possible grade.

TABLE 11-1: The device matrix
ClassMarkupCSSJavaScriptClass AXHTML, XHTML-MP, HTML5CSS2, CSS3Great, includes DHTML, AjaxClass BXHTML, XHTML-MPCSS2 (Decent)Limited, some DHTMLClass CXHTML, XHTML-MPCSS2 (Limited)LimitedClass DXHTML-MPCSS2 (Basic)NoneClass FXHTML-MP, WMLNoneNone
Class A mobile …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_eighth_mass_medium?rev=1299651040&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:10:40-07:00</dc:date>
        <title>The Eighth Mass Medium: What’s Next?</title>
        <link>http://www.mobiledesign.org/the_eighth_mass_medium?rev=1299651040&amp;do=diff</link>
        <description>The argument of the seventh mass medium makes a strong case for how the mobile medium is unique and powerful, but any good investor might ask what is next. I suggest that we are at the beginning of the eighth mass medium, which I’ll call “ubiquity.”</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_elements_of_mobile_design?rev=1299651448&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:17:28-07:00</dc:date>
        <title>The Elements of Mobile Design</title>
        <link>http://www.mobiledesign.org/the_elements_of_mobile_design?rev=1299651448&amp;do=diff</link>
        <description>As I wrote this chapter, I struggled with how to describe how to do design. I personally believe that good design requires three abilities: the first is a natural gift for being able to see visually how something should look that produces a desired emotion with the target audience. The second is the ability to manifest that vision into something for others to see, use, or participate in. The third is knowing how to utilize the medium to achieve your design goals.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_evolution_of_devices?rev=1301376947&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:35:47-07:00</dc:date>
        <title>The Evolution of Devices</title>
        <link>http://www.mobiledesign.org/the_evolution_of_devices?rev=1301376947&amp;do=diff</link>
        <description>Every story has a beginning, and mobile development is no different. Understanding context is something discussed often in this book, and I can think of no better place to start than to go down memory lane and give you the backstory, or historical context, of how we arrived at the mobile technologies of today.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_feature_phone_era?rev=1301377080&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:38:00-07:00</dc:date>
        <title>The Feature Phone Era</title>
        <link>http://www.mobiledesign.org/the_feature_phone_era?rev=1301377080&amp;do=diff</link>
        <description>FIG 1-5The Motorola RAZR, probably the most iconic device from the Feature Phone Era

The third era, the Feature Phone Era (1998–2008), wasn’t nearly as radical a technological leap as the leap from the Brick Era to the Candy Bar Era, but it was an important evolution nonetheless. Up to this point, mobile phones had done three things: make voice calls, send text messages, and play the Snake game. The Feature Phone Era (see FIG 1-5) opened the floodgates to a variety of applications and services …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_future_of_mobile?rev=1300044571&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:29:31-07:00</dc:date>
        <title>The Future of Mobile</title>
        <link>http://www.mobiledesign.org/the_future_of_mobile?rev=1300044571&amp;do=diff</link>
        <description>I like to think about what’s next and what tomorrow’s innovations will be. A question I get asked a lot is “What will the future of mobile be?” The best answer I can think of that comes close to capturing the potential that mobile offers is simply “Everything.” Tomorrow’s innovations will not only involve mobile technology, but they will come from the mobile investments that are made today. This won’t be because of the iPhone or Android phones, operators, or the big device makers, but because of…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_handheld_media_type?rev=1300039098&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:58:18-07:00</dc:date>
        <title>The Handheld Media Type</title>
        <link>http://www.mobiledesign.org/the_handheld_media_type?rev=1300039098&amp;do=diff</link>
        <description>In order to achieve this technique, we are going to rely on the browsers, but luckily there are couple of attributes in XHTML that will help us out. First, let’s talk about the media type attributes, which are basically the parents of media queries. XHTML includes a number of media type attributes that you can add to your document to load different stylesheets for different contexts. For example, when we reference our stylesheet, we can define it as a screen, print, projection, or (the unfortuna…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_mobile_ecosystem?rev=1299912990&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T22:56:30-07:00</dc:date>
        <title>The Mobile Ecosystem</title>
        <link>http://www.mobiledesign.org/the_mobile_ecosystem?rev=1299912990&amp;do=diff</link>
        <description>FIG 2-1

The Internet has spoiled us. We tend to oversimplify the technology powering the Internet. The Internet is actually a complex ecosystem made up of many parts that must all work together seamlessly. When you enter a URL into a web browser, you don’t think about everything that has to happen to see a web page. When you send an email, you don’t care about all the servers, switches, and software that separate you from your recipient. Everything you do on the Internet happens in fractions of…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_mobile_marketing_association?rev=1300041085&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:31:25-07:00</dc:date>
        <title>The Mobile Marketing Association</title>
        <link>http://www.mobiledesign.org/the_mobile_marketing_association?rev=1300041085&amp;do=diff</link>
        <description>The Mobile Marketing Association provides and maintains a number of mobile advertising guidelines, including ad unit sizes as well as code of conduct for mobile marketing, consumer best practices, and other resources for advertisers and publishers. The Mobile Marketing Guidelines are available at &lt;http://mmaglobal.com/mobileadvertising.pdf&gt;.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_mobile_user_experience_is_awful?rev=1299651744&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:22:24-07:00</dc:date>
        <title>The Mobile User Experience Is Awful</title>
        <link>http://www.mobiledesign.org/the_mobile_user_experience_is_awful?rev=1299651744&amp;do=diff</link>
        <description>Traditionally, the user experience available in the mobile web has been like using a website from 1995: mostly text-based, difficult to use, and ugly as sin. This isn’t to say that the user experience of mobile applications has been much better, but it used to be that if you wanted a good experience, you built a native app.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_mobile_web_browser_as_the_next_killer_app?rev=1299651713&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:53-07:00</dc:date>
        <title>The Mobile Web Browser As the Next Killer App</title>
        <link>http://www.mobiledesign.org/the_mobile_web_browser_as_the_next_killer_app?rev=1299651713&amp;do=diff</link>
        <description>If the future of mobile is the Web, then it only makes sense that the mobile web browser is the next killer app of mobile. Again, this is something we saw confirmed with WebKit in the iPhone and later in Android.

However, of particular concern is how device fragmentation factors into mobile browsers. For example, how can we expect developers to support more than 30 different mobile browsers? A fellow panelist from the Mozilla Minimo project offered a potential solution in consolidation—that we …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_one_web_aftermath?rev=1299652326&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:32:06-07:00</dc:date>
        <title>The One Web Aftermath</title>
        <link>http://www.mobiledesign.org/the_one_web_aftermath?rev=1299652326&amp;do=diff</link>
        <description>After the One Web principle was announced, the mobile community, which had been working on this problem for years, exploded in vehement disagreement over the principle. Many people, including myself, called it unrealistic and said that it ignored the needs of mobile users. Meanwhile, the web community applauded the idea, wanting to see the mobile landscape become more aligned with the Web, and demanding smarter mobile web browsers, thus starting a mild feud that continues to this day.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_opportunity_for_change?rev=1300044890&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:34:50-07:00</dc:date>
        <title>The Opportunity for Change</title>
        <link>http://www.mobiledesign.org/the_opportunity_for_change?rev=1300044890&amp;do=diff</link>
        <description>I see systemic flaws with the Web of today—some deep-seated blight in the industry that makes me want to prognosticate a bleak and bland future. I find it difficult to get excited about “me-too” trends like the next Twitter or Facebook. It’s not that these ideas aren’t great and that they can’t stand some healthy competition, but aren’t they just solutions looking for problems? Are they really that important outside a small but vocal cadre that tries to influence others? Are these examples reall…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_page_model?rev=1299652059&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:27:39-07:00</dc:date>
        <title>The Page Model</title>
        <link>http://www.mobiledesign.org/the_page_model?rev=1299652059&amp;do=diff</link>
        <description>The key difference between a mobile website and a mobile web app is the type ofpage model that you use. Mobile web apps usually use a single-page model in which the browser loads one container page of markup. Then, using Ajax, additional content is loaded based on the user’s actions. The user can perform most if not all tasks from this one coded page. In the multipage model, the user traverses a hierarchy of individual pages, designed to lead the user to the desired end goal. In this model, the …</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_smartphone_era?rev=1301377182&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-28T22:39:42-07:00</dc:date>
        <title>The Smartphone Era</title>
        <link>http://www.mobiledesign.org/the_smartphone_era?rev=1301377182&amp;do=diff</link>
        <description>FIG 1-6Early smartphones came from companies like Nokia, Handspring, and Research in Motion (RIM)

The Smartphone Era occurred at the same time as the third and fifth eras and spans from around 2002 to the present. What is and isn’t a smartphone (see FIG 1-6) has never been defined, which explains the overlap in chronology. Although smartphones have all the same capabilities of a feature phone, like making a phone call, sending an SMS, taking a picture, and accessing the mobile web, most smartph…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_switcher?rev=1299652406&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:33:26-07:00</dc:date>
        <title>The Switcher</title>
        <link>http://www.mobiledesign.org/the_switcher?rev=1299652406&amp;do=diff</link>
        <description>The Switcher is a device detection layer to route mobile devices to mobile experiences, available in Java, PHP and .NET, provided by WURFL maintainer Luca Passani.

Whenever an HTTP request is received, the Switcher will analyze each header, checking to see whether it is a mobile device or browser. If it is, the Switcher will direct the requesting client to the URL that’s most appropriate for it. It provides a great deal of customization to suit your specific needs.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_touch_era?rev=1299911903&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-11T22:38:23-07:00</dc:date>
        <title>The Touch Era</title>
        <link>http://www.mobiledesign.org/the_touch_era?rev=1299911903&amp;do=diff</link>
        <description>&quot; Change occurs because there’s a gap between what is and what should be.  —Craig McCaw&quot;


Mobile devices started as simple portable telephones, but they evolved. Messaging was added to mobile capabilities, but mobile devices were still just person-to-person communication tools. We saw networks improve and data speeds increase, which allowed for more technology and more features each year, crammed into smaller and smaller packages. Mobile devices got smarter by learning from desktop computing, t…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_ubiquity_principle?rev=1299986661&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:24:21-07:00</dc:date>
        <title>The Ubiquity Principle</title>
        <link>http://www.mobiledesign.org/the_ubiquity_principle?rev=1299986661&amp;do=diff</link>
        <description>Let me start by clearly stating where I stand on this issue: I believe that the mobile web is the only long-term commercially viable content platform for mobile devices. I have four key reasons to support this belief: fragmentation, the Web, control, and consumer expectations.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/the_web?rev=1299651568&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:28-07:00</dc:date>
        <title>The Web</title>
        <link>http://www.mobiledesign.org/the_web?rev=1299651568&amp;do=diff</link>
        <description>&quot; Anyone who’s betting against the Web right now is an idiot. 
 —Daniel Appelquist, Co-Chair W3C Mobile Web Initiative&quot;


The overall technology market is going to the Web. It is a highly vetted consumer medium that offers many pros and few cons. It is the only medium for information, applications, and services that has gone the distance for the last 15 years. With a new focus on advanced desktop web browser technology, which is poised to become more than just rendering text, the only native app…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/thinking_in_context?rev=1299651067&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:11:07-07:00</dc:date>
        <title>Thinking in Context</title>
        <link>http://www.mobiledesign.org/thinking_in_context?rev=1299651067&amp;do=diff</link>
        <description>Context is probably the most used, underestimated, and misunderstood concept in mobile. I think of it as the chewy nougat in the center of a good candy bar. Sure, the candy bar would be good without it, but it’s that little extra bit that makes the candy bar an incredible experience; no one quite knows what it is, but everyone knows that it tastes good. Actually, that example probably doesn’t help demystify context as much as it makes you crave a candy bar. So let me explain it another way.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/toc?rev=1299650758&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:05:58-07:00</dc:date>
        <title>Table of Contents</title>
        <link>http://www.mobiledesign.org/toc?rev=1299650758&amp;do=diff</link>
        <description>Chapter 1A Brief History of MobileChapter 2The Mobile EcosystemChapter 3Why Mobile?Chapter 4Designing for ContextChapter 5Developing  a Mobile StrategyChapter 6Types of Mobile ApplicationsChapter 7Mobile IAChapter 8Mobile DesignChapter 9Mobile Web Apps vs. Native AppsChapter 10Mobile 2.0Chapter 11Mobile Web DevelopmentChapter 12iPhone Web AppsChapter 13Adapting to DevicesChapter 14Making Money in MobileChapter 15Supporting DevicesChapter 16The Future of Mobile</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/tools_and_libraries?rev=1299652229&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:30:29-07:00</dc:date>
        <title>Tools and Libraries</title>
        <link>http://www.mobiledesign.org/tools_and_libraries?rev=1299652229&amp;do=diff</link>
        <description>Many toolkits and interface libraries have emerged to aid in the creation of mobile web apps, specifically for the iPhone. Building on the work of others can be a huge time saver when trying to build a mobile web app.



PhoneGapiPhone GUI PSD
Table of Contents</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/types_of_mobile_applications?rev=1299651185&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:13:05-07:00</dc:date>
        <title>Types of Mobile Applications</title>
        <link>http://www.mobiledesign.org/types_of_mobile_applications?rev=1299651185&amp;do=diff</link>
        <description>As we’ve already discussed, the mobile ecosystem is a large and deep pool. In fact, it probably isn’t a pool, but an ocean—a really, really big ocean. An ocean is a good metaphor to put the different types of mobile applications in context. You see, in order to traverse an ocean, you need a sturdy boat. Boats of course come in all sorts of shapes and sizes, each with their pros and cons. Some are fast and agile, but carry little cargo. Others are large and lumbering, but can carry tons of people…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/typography?rev=1299984398&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T18:46:38-07:00</dc:date>
        <title>Typography</title>
        <link>http://www.mobiledesign.org/typography?rev=1299984398&amp;do=diff</link>
        <description>The sixth element of mobile design is typography, which in the past would bring to mind the famous statement by Henry Ford:


	&quot; Any customer can have a car painted any color that he wants so long as it is black.&quot;

FIG 8-12What most mobile designers think of when it comes to mobile typography</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/ubiquity_in_the_mobile_web?rev=1299651594&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:19:54-07:00</dc:date>
        <title>Ubiquity in the Mobile Web</title>
        <link>http://www.mobiledesign.org/ubiquity_in_the_mobile_web?rev=1299651594&amp;do=diff</link>
        <description>The mobile web is the only platform that is available and works across all mobile devices, sharing the same set of standards and protocols with each other as well as the desktop web. The mobile web is also the only mobile distribution channel available to developers that they can control. It is the best way to bridge short, context-based mobile interactions with longer, desktop-based tasks.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/ubiquity_starts_with_the_mobile_web?rev=1299959241&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T11:47:21-07:00</dc:date>
        <title>Ubiquity Starts with the Mobile Web</title>
        <link>http://www.mobiledesign.org/ubiquity_starts_with_the_mobile_web?rev=1299959241&amp;do=diff</link>
        <description>We have endured years of bold and usually unfulfilled claims that come from the tech sector. We’ve been promised that the Web will make our lives easier, but aren’t we seeing the opposite reaction? Our lives are becoming so infused with information that it becomes overwhelming and even stressful just to keep up—an increasing problem called information overload.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/usability_testing?rev=1300044468&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:27:48-07:00</dc:date>
        <title>Usability Testing</title>
        <link>http://www.mobiledesign.org/usability_testing?rev=1300044468&amp;do=diff</link>
        <description>Testing a mobile project with actual users always presents invaluable feedback—it gives you an outside perspective directly from your target users. The more you can test your project, the more data and insight you gain into the potential success or failure of your work. As usability guru Jared Spool of User Interface Engineering (&lt;http://www.uie.com&gt;) says, “Talking to two users is better than talking to one.”</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/using_accelerometers?rev=1299651642&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:42-07:00</dc:date>
        <title>Using Accelerometers</title>
        <link>http://www.mobiledesign.org/using_accelerometers?rev=1299651642&amp;do=diff</link>
        <description>A popular feature in more recent mobile devices is the addition of an accelerometer, a small instrument that measures physical acceleration and gravity and sends data back to the device. The most common use of an accelerometer is to detect when the device is physically rotated, adjusting the display from vertical to horizontal orientation (or vice versa).</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/using_cameras?rev=1299651634&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:34-07:00</dc:date>
        <title>Using Cameras</title>
        <link>http://www.mobiledesign.org/using_cameras?rev=1299651634&amp;do=diff</link>
        <description>The camera is another device function that can come in handy in your applications. Traditionally, mobile MMS (Multimedia Messaging Service) is used to handle mobile photo interactions. In other words, you take a photo, send it via MMS to a shortcode, then a server somewhere does something with the photo and sends an alert to you when it is done. This process is complicated, time-consuming, and fairly unreliable.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/using_specific_locations?rev=1299651625&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:20:25-07:00</dc:date>
        <title>Using Specific Locations</title>
        <link>http://www.mobiledesign.org/using_specific_locations?rev=1299651625&amp;do=diff</link>
        <description>The next feature is location, or being able to detect the users’ locations by GPS or cell tower triangulation for the purpose of presenting users with information based on their current location. Traditionally, the only way to access users’ locations is through native application APIs, but the W3C Geolocation API is quickly being incorporated into the most popular mobile browsers. Devices that run WebKit, like the iPhone or Android devices, as well as devices that run the Opera or Mozilla browse…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/using_this_strategy_with_media_queries?rev=1299652334&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:32:14-07:00</dc:date>
        <title>Using This Strategy with Media Queries</title>
        <link>http://www.mobiledesign.org/using_this_strategy_with_media_queries?rev=1299652334&amp;do=diff</link>
        <description>We’ve clearly seen in terms of usage with more advanced mobile browsers, such as WebKit or Opera, that when rendering normal web content at desktop quality users, when given the choice, prefer the mobile optimized version designed for the mobile content instead of the often more full-featured desktop version. This actually means that the One Web principle does work if the first four of the assumptions about One Web are true.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/utility_context?rev=1299966589&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T13:49:49-07:00</dc:date>
        <title>Utility Context</title>
        <link>http://www.mobiledesign.org/utility_context?rev=1299966589&amp;do=diff</link>
        <description>FIG 6-8An example utility application

The most basic application context is the utility, or a simple user experience metaphor that is meant to address short, task-based scenarios. Information is meant to be presented in a minimal fashion, often using the least amount of user input as possible. An example of a utility might be a calculator, weather forecast, unit conversion, stocks, world clock, and so on. In each of these cases, the user enters a small amount of information into the utility, li…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/visual_effects?rev=1299993691&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T21:21:31-07:00</dc:date>
        <title>Visual Effects</title>
        <link>http://www.mobiledesign.org/visual_effects?rev=1299993691&amp;do=diff</link>
        <description>There are a number of visual effects that you can perform specifically with the iPhone and iPod touch. These effects are part of the WebKit distribution, but not all devices that use WebKit support them—at least, not yet. This is largely due to how the iPhone is able to offload visual effects to the GPU efficiently, something that is a bit more of a challenge with platforms that are loaded onto licensed hardware, as in the case of Android devices.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/volantis?rev=1299652514&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:35:14-07:00</dc:date>
        <title>Volantis</title>
        <link>http://www.mobiledesign.org/volantis?rev=1299652514&amp;do=diff</link>
        <description>One of the larger content adaptation vendors, Volantis—like many adaptation solution providers—maintains its own proprietary device database. It has its own testing laboratory, and tests and records all device capabilities to enable it to work with its primary product. Its device detection service is included in all its service plans, but expect the pricing to be out of reach for all but a few. Volantis does, however, provide an open source version of its Java-based software that includes an old…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/wall_and_wng?rev=1299652522&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:35:22-07:00</dc:date>
        <title>WALL and WNG</title>
        <link>http://www.mobiledesign.org/wall_and_wng?rev=1299652522&amp;do=diff</link>
        <description>WALL (Wireless Abstraction Library) and WNG (WALL Next Generation) are adaptation libraries written by WURFL’s Luca Passani. WNG is the more modern tool, building on the success of WALL as a way to abstract content and adapt it on the fly.

An example JSP page written with WNG might look like this:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/we_are_creator_not_consumers?rev=1299987225&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:33:45-07:00</dc:date>
        <title>We Are Creator, Not Consumers</title>
        <link>http://www.mobiledesign.org/we_are_creator_not_consumers?rev=1299987225&amp;do=diff</link>
        <description>The final principle of Mobile 2.0 is recognizing that we are in a new age of consumerism. Yesterday’s consumer does not look anything like today’s consumer. The people of today’s market don’t view themselves as consumers, but rather as creators. But before we get into that, let’s back up for a minute.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/web_apps_as_native_app?rev=1300037468&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:31:08-07:00</dc:date>
        <title>Web Apps as Native App</title>
        <link>http://www.mobiledesign.org/web_apps_as_native_app?rev=1300037468&amp;do=diff</link>
        <description>It is hard to look at mobile technology and not immediately veer toward building a native application. You can check the user’s location, play back local media, interact with the user’s address book, plus a whole host of other features that tap into the device’s potential. When you add that the APIs are well documented, the storefronts are massive, and that you can actually charge people for the app, it can be hard to make a case for creating a mobile web app versus a native app.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/web_standards?rev=1299651792&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:23:12-07:00</dc:date>
        <title>Web Standards</title>
        <link>http://www.mobiledesign.org/web_standards?rev=1299651792&amp;do=diff</link>
        <description>The first question that probably pops into your head (as it certainly does in mine as I write this) is why do we need to have a chapter specifically about mobile web development at all? Isn’t that what the concept of “web standards” is all about? To separate content from presentation in order to create a ubiquitous experience that can be rendered on any device or in any viewing context? In a word, yes, but unfortunately it isn’t that cut-and-dry.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/webkit?rev=1300043121&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T12:05:21-07:00</dc:date>
        <title>WebKit</title>
        <link>http://www.mobiledesign.org/webkit?rev=1300043121&amp;do=diff</link>
        <description>FIG 15-6Desktop testing with the WebKit browser

The WebKit browser engine can also be used for desktop testing for WebKit-based mobile applications. You can download the nightly builds of WebKit and run them on your desktop, giving you a close representation of how it may render on the target device, as shown in FIG 15-6.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/what_about_the_mobile_web?rev=1300040870&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:27:50-07:00</dc:date>
        <title>What About the Mobile Web</title>
        <link>http://www.mobiledesign.org/what_about_the_mobile_web?rev=1300040870&amp;do=diff</link>
        <description>Surely we can build a mobile web app and deploy and sell it through an app store? Yes, you can. In Chapter 12, I mentioned the PhoneGap project, which enables you to take a mobile web app and deploy it as a native app for iPhone, Android, and BlackBerry. As it is an open source project, there are also active ports for Nokia and Windows Mobile platforms.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/what_domain_do_i_use?rev=1300039942&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:12:22-07:00</dc:date>
        <title>What Domain Do I Use</title>
        <link>http://www.mobiledesign.org/what_domain_do_i_use?rev=1300039942&amp;do=diff</link>
        <description>Ideally, the user should have to enter only your primary URL—for example, domain.com—and your multiserving system should route him to the appropriate experience for his device and context. There are some who believe that the users should control which experience they see, and therefore your mobile experiences should live at a separate URL. I am not one of those people.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/what_is_information_architecture?rev=1299973664&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T15:47:44-07:00</dc:date>
        <title>What is Information Architecture?</title>
        <link>http://www.mobiledesign.org/what_is_information_architecture?rev=1299973664&amp;do=diff</link>
        <description>Before we get into the specifics of mobile information architecture, let’s first talk about exactly what information is. I can think of no better definition than the seminal O’Reilly book Information Architecture for the World Wide Web by Morville and Rosenfeld, otherwise known in information architect circles as the “polar bear” book. This definition outlines the following:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/what_is_mobile_2.0?rev=1299651690&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:30-07:00</dc:date>
        <title>What is Mobile 2.0?</title>
        <link>http://www.mobiledesign.org/what_is_mobile_2.0?rev=1299651690&amp;do=diff</link>
        <description>In autumn 2006, I was asked to help design and build a website for the first Mobile 2.0 conference, happening a few days before O’Reilly’s Web 2.0 Summit. The event was put together by several Mobile Monday organizers. Mobile Monday is a series of mobile social gatherings that happen all over the world on the first Monday of the month. The idea was to bring some of the greatest minds in the mobile field together in San Francisco to attend the Web 2.0 Summit in order to discuss the future of mobi…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/what_makes_it_a_mobile_web_app?rev=1299991518&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:45:18-07:00</dc:date>
        <title>What Makes It a Mobile Web App</title>
        <link>http://www.mobiledesign.org/what_makes_it_a_mobile_web_app?rev=1299991518&amp;do=diff</link>
        <description>Technically, any content viewed in a web browser can be considered a website, but we are certainly seeing a subset of experiences that are defined in the mobile context as web applications, or web apps. Apple has taken this to heart with Safari on the iPhone and WebKit, adding several proprietary tricks to tell Mobile Safari that the content in view is a web app intended for the iPhone, and not just a website.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/when_to_make_a_mobile_web_application?rev=1299651671&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:21:11-07:00</dc:date>
        <title>When to Make a Mobile Web Application</title>
        <link>http://www.mobiledesign.org/when_to_make_a_mobile_web_application?rev=1299651671&amp;do=diff</link>
        <description>I believe that unless your application meets one of these native application criteria, you should not create a native application, but should instead focus on building a mobile web application. Like I said before, I’m a big fan of native applications and I feel that there are a lot of great innovative and market opportunities here, but mobile web apps are the only long-term viable platform for mobile content, services, and applications.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/when_to_make_a_native_application?rev=1299986894&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:28:14-07:00</dc:date>
        <title>When to Make a Native Application</title>
        <link>http://www.mobiledesign.org/when_to_make_a_native_application?rev=1299986894&amp;do=diff</link>
        <description>I’m obviously a big supporter of the mobile web; however, I am the first one to admit that making a native application can be the best thing for a product. This is usually true when you need to take advantage of the features of a device that a mobile web browser does not allow.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/why_is_adaptation_a_necessity?rev=1300038712&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T10:51:52-07:00</dc:date>
        <title>Why Is Adaptation a “Necessity”</title>
        <link>http://www.mobiledesign.org/why_is_adaptation_a_necessity?rev=1300038712&amp;do=diff</link>
        <description>FIG 13-1Serving multiple contexts can be redundant and expensive

Is multiserving a “necessity” like Luca suggests, and if so, why? Yes, multiserving your content in one way or another is absolutely a necessity. If you have a website and you want to have a mobile website, web app, or even native application that shares content in some way with another context, you are going to need to figure out a strategy to make that happen.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/why_mobile?rev=1299651002&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:10:02-07:00</dc:date>
        <title>Why Mobile?</title>
        <link>http://www.mobiledesign.org/why_mobile?rev=1299651002&amp;do=diff</link>
        <description>It is hard to think about mobile development apart from the buzz it generates. I wish I could tell you that the majority of mobile strategies start with a well-thought-out plan of how to use the medium to meet the needs of users or further the goals of the business. The people at the majority of companies I visit, those I meet at conferences, those writing articles online, and even a few mobile experts claim that mobile is the next big thing, but few can explain why. This is something I have str…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/why_webkit?rev=1299652025&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:27:05-07:00</dc:date>
        <title>Why WebKit</title>
        <link>http://www.mobiledesign.org/why_webkit?rev=1299652025&amp;do=diff</link>
        <description>A common question during my talks about mobile design and development is why I am such a big proponent of the iPhone and WebKit. If there are a number of other browsers that are actually technically superior, support even more standards, or even have a higher market penetration, how can I in good conscience recommend prioritizing development around the iPhone first, and in some cases recommend solely focusing on the iPhone?</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/wireframes?rev=1299980009&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T17:33:29-07:00</dc:date>
        <title>Wireframes</title>
        <link>http://www.mobiledesign.org/wireframes?rev=1299980009&amp;do=diff</link>
        <description>FIG 7-9An example of an iPhone web application wireframe, intended to be low fidelity to prevent confusion of visual design concepts with information design concepts

The next information architecture tool at our disposal is wireframes. Wireframes are a way to lay out information on the page, also referred to as information design. Site maps show how our content is organized in our informational space; wireframes show how the user will directly interact with it. Wireframes are like the peanut bu…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/wireless_css_and_css-mp?rev=1299651940&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:25:40-07:00</dc:date>
        <title>Wireless CSS and CSS-MP</title>
        <link>http://www.mobiledesign.org/wireless_css_and_css-mp?rev=1299651940&amp;do=diff</link>
        <description>For markup, we have XHTML-MP, a descendant of XHTML; it only makes sense that we have a mobile equivalent for CSS. In fact, we have two: Wireless CSS (sometimes referred to as W-CSS or WAP CSS) managed by the OMA and part of WAP 2.0 along with XHTML-MP. And then we have CSS-MP, or CSS Mobile Profile, managed by the W3C. So, in case you are keeping score: the OMA owns XHTML-MP and W-CSS, and the W3C owns XHTML Basic and CSS-MP.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/wordpress_mobile_plug-in?rev=1300039490&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:04:50-07:00</dc:date>
        <title>WordPress Mobile Plug-in</title>
        <link>http://www.mobiledesign.org/wordpress_mobile_plug-in?rev=1300039490&amp;do=diff</link>
        <description>As mentioned before, Andy Moore developed a plugin for the WordPress blogging tool, which is very popular and free. As an increasing number of people start to use WordPress for purposes beyond personal blogging, this plugin makes a simple and easy way to do device targeting. This script not only does the detection, but also provides light adapting as well.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/working_off_deck?rev=1299652487&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:34:47-07:00</dc:date>
        <title>Working “Off Deck”</title>
        <link>http://www.mobiledesign.org/working_off_deck?rev=1299652487&amp;do=diff</link>
        <description>Now there are actually plenty of cases where you might want to use a full adaptation strategy, or least a pseudoadaptation strategy, which is greater than just detecting and routing, but less than completely dynamic. This is normally referred to in the mobile community as being “off deck,” which usually means delivering content to multiple mobile devices over the Web and not through an operator.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/working_on_deck?rev=1299652479&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:34:39-07:00</dc:date>
        <title>Working “On Deck”</title>
        <link>http://www.mobiledesign.org/working_on_deck?rev=1299652479&amp;do=diff</link>
        <description>The publishers that employ full adaptation are usually the ones working with operators to put their content on the operators’ mobile portal, often referred to as a “deck.” At this point, we haven’t discussed much about the last part of multiserving: delivery. To ensure that your detection and adaptation system works, you need to test and confirm that it is finally delivered to the device successfully. With most multiserving strategies, you can typically test anywhere from 10–20 different devices…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/working_with_an_app_store?rev=1300040818&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:26:58-07:00</dc:date>
        <title>Working with an App Store</title>
        <link>http://www.mobiledesign.org/working_with_an_app_store?rev=1300040818&amp;do=diff</link>
        <description>FIG 14-3The Apple App Store

Originally, if you wanted to sell something to a mobile user, the only option was to work with the operator, but as smartphones become more popular, we see the emergence of the platform-based app store (see FIG 14-3). The clearest example of this is the Apple App Store, where users can purchase and download games and applications for their iPhones or iPod touches. But we are also seeing app stores like Nokia’s Ovi Store; Android Market; and stores for BlackBerry, Pal…</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/working_with_operators?rev=1300040440&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:20:40-07:00</dc:date>
        <title>Working with Operators</title>
        <link>http://www.mobiledesign.org/working_with_operators?rev=1300040440&amp;do=diff</link>
        <description>As discussed in Chapter 2, theoperator is at the center of the entire mobile ecosystem. For better or worse, everyone—even the device makers—have to play by the operator’s rules. Every aspect of the industry is guided by its influence. If you are lucky, you will never need to work with an operator at all, but in the right situations, the operator can be an ally and a mutually beneficial friend.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/wurfl?rev=1299652495&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:34:55-07:00</dc:date>
        <title>WURFL</title>
        <link>http://www.mobiledesign.org/wurfl?rev=1299652495&amp;do=diff</link>
        <description>WURFL, or the Wireless Universal Resource File (&lt;http://wurfl.sourceforge.net&gt;), is an open source database of device profiles. It is a massive endeavor—the largest and one of the most active open source projects in mobile. WURFL founder Luca Passani defines the project like this:</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/xhtml-mp_overview?rev=1299987972&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T19:46:12-07:00</dc:date>
        <title>XHTML-MP Overview</title>
        <link>http://www.mobiledesign.org/xhtml-mp_overview?rev=1299987972&amp;do=diff</link>
        <description>XHTML-MP is a modularization of XHTML Basic. XHTML Basic is a subset of XHTML. In other words, if you know XHTML, chances are good that you will be comfortable with XHTML-MP. Now that XHTML Basic and XHTML-MP are virtually indistinguishable, and thanks to both standards being a subset of XHTML—the standard language of the Web—the average web developer does not need to understand a language for each medium.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/xhtml?rev=1299991902&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-12T20:51:42-07:00</dc:date>
        <title>XHTML</title>
        <link>http://www.mobiledesign.org/xhtml?rev=1299991902&amp;do=diff</link>
        <description>When the HTML standard was published in 1990, it was designed for formatting and laying out elements on the screen contextually. For the most part, it was logical, but there were some exceptions that made parsing it quirky. For instance, the open line-break tag &lt;br&gt; did not need to be closed.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/yahoo_blueprint?rev=1300039811&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-13T11:10:11-07:00</dc:date>
        <title>Yahoo! Blueprint</title>
        <link>http://www.mobiledesign.org/yahoo_blueprint?rev=1300039811&amp;do=diff</link>
        <description>FIG 13-4Using Yahoo! Blueprint to adapt and deliver to multiple devices

Yahoo! Blueprint is another adaptation service, which allows you to host applications on your own server but use the Blueprint XML markup language, loosely based on XForms, to adapt and deliver them to multiple devices, as shown in FIG 13-4.</description>
    </item>
    <item rdf:about="http://www.mobiledesign.org/you_can_t_support_everything?rev=1299651160&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2011-03-08T22:12:40-07:00</dc:date>
        <title>You Can’t Support Everything</title>
        <link>http://www.mobiledesign.org/you_can_t_support_everything?rev=1299651160&amp;do=diff</link>
        <description>One of the first steps in building a mobile strategy is taking an honest look at what devices you can support. I’m here to tell you that you can’t support everything.

There are literally hundreds of various device models sold around the world each year. And there are dozens of browsers, each with their own quirks. Think about testing a desktop site for Internet Explorer 6, a web browser notorious for its awful web standards support but immense in its market share, meaning that you have to do a …</description>
    </item>
</rdf:RDF>

