Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You don't HAVE to design two different sites, but you probably want to if it's important to let mobile users access your site.</p> <p>There are a few ways to deal with this problem, each with pros and cons. I'm assuming that your site has its information in a database, and publishes that data using a set of templates? (Like a Ruby on Rails or Django site; a PHP site; a blog; etc.) If you've hand-coded a bunch of static HTML pages, this is going to be way more labor intensive for you.</p> <p><strong>1: Same HTML, different stylesheets for SCREEN and MOBILE</strong></p> <p>The idea: You deliver the same HTML structure to all requests. You create a stylesheet for SCREEN and one for MOBILE. </p> <p>Good: For you, the programmer. It's easier for you to maintain 2 stylesheets than it is to maintain 2 totally separate template sites.</p> <p>Bad: For your users. A site that's easy to use on a mobile device usually is inefficient for a normal browser; and sites optimized for a desktop / laptop often fail miserably on a mobile device. Obviously it depends on how you code your pages, but in most cases, pushing your normal site to a mobile browser will be bad for your users. (See <a href="http://www.useit.com/alertbox/mobile-usability.html" rel="nofollow noreferrer">http://www.useit.com/alertbox/mobile-usability.html</a> for a summary of Jakob Nielsen's recent usability research on mobile sites.)</p> <p><strong>2: Maintain separate sites</strong></p> <p>(Gmail maintains even more than 2 systems! They basically have different container applications / templates that process the same data: the full AJAX browser version; the plain HTML browser version; a basic mobile version; a native Blackberry application; and a native iPhone application.)</p> <p>This is the emerging standard for sites that really care about having both a mobile and desktop presence. It's more work for you, but in general it's much better for your users. </p> <p>On the upside, you can probably create one stripped down pure HTML site that works for mobile and that acts as a fallback for the rare web user who doesn't have javascript, or who has major accessibility issues that prevent them from using the "full" site. </p> <p>Also, depending on your user base: in the US, people generally have access to a desktop / laptop, and use their mobile devices for auxiliary access. For example, I book my plane tickets and rental car using my desktop computer, but I want to look up my reservation code on my mobile. In many cases, you can get away with limiting the functionality that you offer on the mobile site, and require the full computer to perform uncommon use cases. </p> <p>The basic procedure:</p> <ol> <li>Design &amp; build UIs for mobile and screen. </li> <li>Launch the sites at two different URLs; the emerging convention is www.yoursite.com for the desktop version, and m.yoursite.com for the mobile version. (This allows users to browse directly to m.yoursite.com if they know of the convention.)</li> <li>On www.yoursite.com, sniff the user agent and test to see if the user's browser is mobile. If so, direct the user to m.yoursite.com. <ol> <li>There are sniffers written in various server languages (PHP, Perl, whatever) that you can probably use. Check the licenses. <a href="http://detectmobilebrowsers.mobi/" rel="nofollow noreferrer">Here's an example of a sniffer written in php</a>.</li> <li>From <a href="http://en.wikipedia.org/wiki/User_agent" rel="nofollow noreferrer">Wikipedia's article on user agent sniffing</a>: "Websites specifically targeted towards mobile phones, like NTT DoCoMo's I-Mode or Vodafone's Vodafone Live! portals, often rely heavily on user agent sniffing, since mobile browsers often differ greatly from each other. Many developments in mobile browsing have been made in the last few years, while many older phones that do not possess these new technologies are still heavily used. Therefore, mobile webportals will often generate completely different markup code depending on the mobile phone used to browse them. These differences can be small (e.g. resizing of certain images to fit smaller screens), or quite extensive (e.g. rendering of the page in WML instead of XHTML)."</li> </ol></li> <li>On m.yoursite.com, provide a link back to www.yoursite.com. Users who click on this link should NOT be redirected back to the mobile site, and how you accomplish this depends on your implementation.</li> </ol> <p>You may want to follow <a href="http://www.quirksmode.org/blog/archives/2009/03/testing_mobile.html" rel="nofollow noreferrer">Quirksmode</a> for his emerging articles about mobile testing.</p> <p><strong>3: Templates output different data chunks depending on the user-agent, and maintain separate stylesheets</strong></p> <p>Like (2), this requires you to sniff the user agent. Unlike (2), you're still using all the same page logic and don't have to maintain two separate sites. This might be okay if you're just dealing with a blog or website that's mostly about reading data.</p> <p>In your template code, you can say things like</p> <pre><code>if( $useragentType != mobile ) { echo( 'bigBlockOfRelatedArticlesAndAds.php' ); } </code></pre> <p>This lets you mostly maintain one set of template files. You can also streamline the pages that you're sending to your mobile users, so they don't get a big bloated page when they just wanted to read your blog post or whatever.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow can i design a site for mobile phones
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USElBel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow can i design a site for mobile phones
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload