Should we standardize a "t" subdomain?

RJM62

Touchdown! Greaser!
Joined
Jun 15, 2007
Messages
13,157
Location
Upstate New York
Display Name

Display name:
Geek on the Hill
It occurs to me that because designers now have to accommodate devices with widely varying optimal viewport sizes, it might be a good idea to standardize a "t" subdomain in addition to the "m" subdomain for mobile devices.

When the "m" came into use, it assumed a tiny viewport, slow connections, expensive bandwidth, and funky image rendering; so sites that were designed as "mobile" are too stripped down for tablets.

But on the other hand, there are sites that people might very well want to access from their phones, so I think we still need a standard specifically for those devices.

For example, let's consider a hypothetical site for a plumbing or electrical supply company. It would include pictures of the parts they sell to help users identify the parts they need, even if they have no Internet access other than their phones. This might be the case if someone is working on a new home or a vacation home, or if they're a plumber or electrician working in the field who come across a problem and need a part to fix it.

For a site like that, it would make the most sense to have a phone-optimized version that uses, say, medium-quality, centered images that render at viewport width and are zoomable, placed above or below the item description. This way the guy standing in two feet of water in a basement can quickly find the sump pump part that he needs.

On a tablet or desktop, however, the images might look better and be more useful rendered at, say, x% of horizontal viewport size with a max-width of x-px, and floated right, with the descriptive information to the left.

Design aesthetics- and usability-wise, however, the desktop version might want to use more columns, the images might be of higher quality (which would eat up bandwidth for mobile users), they might want to use hover zoom, they might open in a lightbox that doesn't work well or is inconvenient on tablets, etc.

Suffice it to say that there are effects that can be useful to users (or just pretty) that simply won't work on tablets. With minor tweaking of things like navigation menus and such, desktop versions can work well enough on tablet versions. But with a little more tweaking, both versions can quite easily be optimized to their particular experience with just a few minutes of CSS. So why not have a "t" subdomain for tablets?

As a designer, I consider the tablet experience to be a step backward. I really don't understand why anyone likes them. I understand why people use them in certain cases where mobile connectivity is needed or desired, but not why they like them. An outhouse is a fine place to take a dump when I'm camping, but I don't plan to build one behind my house because I have two nicely-equipped bathrooms with running water. That's how I look at tablets. I'll use them if I have to, but I scratch my head wondering why some people actually prefer using them.

Nonetheless, some people do. Still, I don't want to limit my designs to those that will work on a tablet. It's a simple thing to build a second version optimized to a tablet, and a third version optimized for a phone. They all can call the same content, and CSS and PHP can be used to render that content appropriately for the devices.

So I propose that the "t" subdomain be set aside for tablets, and the "m" for phones.

-Rich
 
Last edited:
I propose getting rid of both. I can't recall a time, even on my iPhone that I wanted to see the mobile version of a site.

As CSS evolves, detecting view ports and accommodating them is getting easier.

I'm a fan of responsive website design and getting rid of mobile specific development.
 
I propose getting rid of both. I can't recall a time, even on my iPhone that I wanted to see the mobile version of a site.

I concur with this. Web browsing on even the newer iPhones is not the most enjoyable and I avoid it if possible.

With the iPad 2, I use Safari very frequently. And then Photon to view sites built on Flash content (like ilearn.kingschools.com).

If I had owned a phablet like the Galaxy, then maybe I'd browse more on the phone. But for now, I get the small chunk of web content I'm seeking from either a related app, or a google search.
 
How about we have developers that don't automatically redirect you to the ****ing mobile site????

Even when I tell the device/browser to spoof it's not a mobile, they STILL find a way to determine it. Those developers should be be made to participate in the BME Olympics.
 
Last edited:
How about we have developers that don't automatically redirect you to the ****ing mobile site????

Even when I tell the device/browser to spoof it's not a mobile, they STILL find a way to determine it.

In my experience marketing makes those decisions in spite of protesting from the developers... don't shoot the messenger. Developers are the reason you have "View Full Site" options.... it's the compromise we had to make.
 
In my experience marketing makes those decisions in spite of protesting from the developers... don't shoot the messenger. Developers are the reason you have "View Full Site" options.... it's the compromise we had to make.

Oh, no. I've run into the ones that don't have a "full site" link anywhere on the mobile site. In fact, most I've run into DON'T have it - or it's impossible to find.
 
Oh, no. I've run into the ones that don't have a "full site" link anywhere on the mobile site. In fact, most I've run into DON'T have it - or it's impossible to find.

In my experience, that's marketing's decision.

Come to think of it, I don't think I've ever written a mobile site for anything but a marketing effort.
 
Oh, no. I've run into the ones that don't have a "full site" link anywhere on the mobile site. In fact, most I've run into DON'T have it - or it's impossible to find.

I made that mistake once and got many angry emails as a result. Since then, I give the user the choice. I don't even try to sniff anymore because too many people spoof.

Sometimes I use a cookie to record the user's preference, but I'm finding that on small sites it's just as easy to build a parallel site with the same page filenames. It really only comes down to a few files because all the content is drawn from the same place. So it basically needs a header, a footer, and the stylesheet.. sometimes a few other files or scripts, depending on complexity.

The versions have the same page filenames, so creating links back and forth is silly simple. For example:

PHP:
<? $tablet = "http://t.mainsite.com" . $_SERVER["PHP_SELF"]; ?>
<p>This is the full version of my site.  <a href="<? echo $tablet; ?>">Click Here</a> for the Tablet-Friendly version of this page.</p>
I decided yesterday evening to toy around with a more tablet-friendly version of my Kitchen Table Computers site. It took maybe an hour, if that much, most of which was spent revising a few images and choosing new ads. As of this morning, the tablet version had 274 unique visitors (not including robots and such), most of whom connected through wireless providers. The only places it was linked from were the main site and its forum, and there's no sniffing. So I'd have to say people like the choice.

The tablet version, which may have a few glitches (again, I slapped it together in less than an hour), is at:

[ link removed ]

It's by no means "finished." I want to tweak the menu, and the CSS here and there, as well as clean up CSS that's not needed for this version. I also retained a few effects (hover text links, etc.) for those few mobile devices that have the ability to hover. They don't hurt anything in less capable devices. They simply don't do anything.

-Rich
 
Last edited:
I'd suggest you don't use m or t. It's bad for SEO. Just do it responsive on the main domain.
 
I'd suggest you don't use m or t. It's bad for SEO. Just do it responsive on the main domain.

The "t" is non-standard, so I'm concerned about that. But do you think the "m" is a problem, as well? I thought that "m" was accepted by search engines re: uniqueness-of-content penalties and so forth, and I haven't had problems SEO-wise using "m"... so far...

Yahoo certainly seems to get it. If I do a search on my phone using Yahoo, the results (for one of my own sites) come up on the "m;" but if I'm on a computer, they come up on the main domain. On Google, the "m" seems to be pretty much ignored, which is also fine, because visitors can get there from the main sites. In any event, I was under the impression that search engines kind of understood the "m," and was thinking that doing the same for "t" would be nice.

Of course, I could be wrong. It has happened before. Often.

The reason I ask is because one idea I was toying around with was making a responsive version for both tablets and phones, and sticking it in "m." I would then use .htaccess redirects to move the hits on "t" to "m" on sites that previously had been using "t." Of course, I would do this on one of my own sites -- probably this one, because it's the only one I've tried the "t" on.

Thanks,

-Rich
 
Bad fix for a non-existent problem. Ask the browser what it is and code the website accordingly.
 
Bad fix for a non-existent problem. Ask the browser what it is and code the website accordingly.
+1 You can achieve everything you're wanting to achieve on one domain via many different methods.
 
CSS Media queries solve this. Particularly if your designs are responsive.

As long as the user can override the selection, which is easy enough to do with a cookie and a couple of lines of code pointing to the correct stylesheet (and possibly another image directory, etc. on some sites).

I still have a few very old mobile versions of client sites that were coded with EDGE in mind because the main sites were very media-heavy and took forever to load on a phone. And I still get users on dialup who prefer those versions. I also have one client with a very image-heavy site that has an option to not render the galleries, which also is preferred by a lot of visitors. It just sets a cookie.

Of course, a slim possibility exists that a great deal of my conflict reflects my own stubbornness, more than any technical factors... :mad2:

-Rich
 
FWIW - I agree that you shouldn't do this at all, but who cares about a standard? If you're going to do this, you could just as easily do "asdfasdfasdx.domain.com" and it will work fine if you're redirecting. I don't know of anyone that intentionally goes to m.domain.com.

Also, I've seen just as many mobile.domain.com as I've seen m.domain.com.
 
As long as the user can override the selection, which is easy enough to do with a cookie and a couple of lines of code pointing to the correct stylesheet (and possibly another image directory, etc. on some sites).

Override what selection? It's a design challenge to design a site that looks and flows well in both ancient iphone 320x480, a retina 2560x1600 display, and everything in between. I've never liked "dumbed down" mobile-version sites, and would rather designers just didnt design for mobile at all if they are going to do that and let the mobile user just pan around for content.

I've found the media-query CSS overrides usually add 5 or 10% to a well-designed site's CSS, and that's for all of the major mobile screens (iphone, iphone retina, ipad, ipad retina, various flavors of android and WMP, plus stock desktop res's). Way better than a CMS/template engine or maintaining two versions in my book. Of course each design is different.

:dunno:
 
FWIW - I agree that you shouldn't do this at all, but who cares about a standard? If you're going to do this, you could just as easily do "asdfasdfasdx.domain.com" and it will work fine if you're redirecting. I don't know of anyone that intentionally goes to m.domain.com.

Also, I've seen just as many mobile.domain.com as I've seen m.domain.com.

Well, standardization would help with search engines more than for any other reason.

Responsive design solves a lot of cross-platform problems, but it's not a panacea -- especially when dealing with a site that already exists, and that the client likes, but which doesn't work well on mobile platforms. It's also a tad limiting design-wise, although CSS3 does allow that to be worked around on a new site.

I've gotten a dozen or so quick jobs over the past year from people who wanted me to do one thing: make their menus work on tablet devices. Most of these folks had built their own sites using some WYSIWYG program that built a hover-dependent menu. The first was a local guy who runs a combination motel / restaurant / kayak rental / sporting goods / bait shop sort of place that, obviously, depends on tourists. He built his own site, but noticed that his traffic had been dwindling. Then one day, to his horror, he bought an iPhone and discovered that he couldn't expand the nav menu. That seems to be the case with most folks who have contacted me about that problem.

Hey, it's quick, easy work, so I'm not complaining. For the poor and/or tightwad clients, I can bang out a quickie menu in minutes for beer money using a DW extension I bought for $29.00; or I can hand-code something prettier in a few hours if the client is willing to pay for it.

But either way, it does make me wonder why more tablet devices didn't support hover from the start when so many millions of existing nav menus require it. That was, in my opinion, a stroke of idiocy. Even my old trackball phones supported hover. It could have been done on a tablet with tap interva, touch times, a trackball or pad... something that allowed the millions of blasted hover-dependent menus on the Web to actually work.

-Rich
 
Well, standardization would help with search engines more than for any other reason.

Responsive design solves a lot of cross-platform problems, but it's not a panacea -- especially when dealing with a site that already exists, and that the client likes, but which doesn't work well on mobile platforms. It's also a tad limiting design-wise, although CSS3 does allow that to be worked around on a new site.

I've gotten a dozen or so quick jobs over the past year from people who wanted me to do one thing: make their menus work on tablet devices. Most of these folks had built their own sites using some WYSIWYG program that built a hover-dependent menu. The first was a local guy who runs a combination motel / restaurant / kayak rental / sporting goods / bait shop sort of place that, obviously, depends on tourists. He built his own site, but noticed that his traffic had been dwindling. Then one day, to his horror, he bought an iPhone and discovered that he couldn't expand the nav menu. That seems to be the case with most folks who have contacted me about that problem.

Hey, it's quick, easy work, so I'm not complaining. For the poor and/or tightwad clients, I can bang out a quickie menu in minutes for beer money using a DW extension I bought for $29.00; or I can hand-code something prettier in a few hours if the client is willing to pay for it.

But either way, it does make me wonder why more tablet devices didn't support hover from the start when so many millions of existing nav menus require it. That was, in my opinion, a stroke of idiocy. Even my old trackball phones supported hover. It could have been done on a tablet with tap interva, touch times, a trackball or pad... something that allowed the millions of blasted hover-dependent menus on the Web to actually work.

-Rich

FWIW, on most Android devices at least, you can sort of trick it by tapping, holding for a second, and then dragging off the menu. Often, the menu will stay up long enough to allow a second tap to select the menu item.

What I had my vendors do in the past was design menus in a way that when the screen gets below a certain size (read: responsive design), I change the menu to a click drop down instead. Its like 5 extra lines of code, plus an additional 5 to detect screen size, and its pretty elegant.

For reference, check out http://www.zonnic.com and its menu structure. Works really well.
 
FWIW, on most Android devices at least, you can sort of trick it by tapping, holding for a second, and then dragging off the menu. Often, the menu will stay up long enough to allow a second tap to select the menu item.

What I had my vendors do in the past was design menus in a way that when the screen gets below a certain size (read: responsive design), I change the menu to a click drop down instead. Its like 5 extra lines of code, plus an additional 5 to detect screen size, and its pretty elegant.

For reference, check out http://www.zonnic.com and its menu structure. Works really well.

I don't see any sort of multilevel menus on that site...

In any case, I agree that making a nav menu work (unless it's a really funky JS menu) without hover is easy. But I still wonder about the thought processes that went into designing a high-end Internet access device that can't access millions of existing menus. I mean, didn't someone in R&D slap his forehead when he realized that he couldn't navigate half the world's Web sites?

-Rich
 
I don't see any sort of multilevel menus on that site...

In any case, I agree that making a nav menu work (unless it's a really funky JS menu) without hover is easy. But I still wonder about the thought processes that went into designing a high-end Internet access device that can't access millions of existing menus. I mean, didn't someone in R&D slap his forehead when he realized that he couldn't navigate half the world's Web sites?

-Rich

Hover menus in general are bad design IMO and have been for some time. Likely the powers that be felt the same.
 
Hover menus in general are bad design IMO and have been for some time. Likely the powers that be felt the same.

The powers that be?

Has Apple replaced 3WC? :dunno:

Even if hover menus suck, Apple still released a product intended as an Internet access device, but which couldn't navigate many valid 3WC-compliant sites -- and a whole mess of them, at that. Then the others followed Apple's lead in taking away that functionality.

To me that's like designing a car that can't make left turns. It actually would be safer -- a lot more accidents occur making left turns than right turns, and the fatality rates are much higher. Also, there's a workaround: You can just make three right turns to go left. So why not just do away with left turns -- and to force the issue, let's take that ability away from cars because left turns are bad design. And if there are some places where those cars simply can't go, well, that's the cost of doing things right.

Meh. It is what it is, and it's easy enough to fix on the design end. I'm just becoming a curmudgeon is all.

-Rich
 
The powers that be?

Has Apple replaced 3WC? :dunno:

Even if hover menus suck, Apple still released a product intended as an Internet access device, but which couldn't navigate many valid 3WC-compliant sites -- and a whole mess of them, at that. Then the others followed Apple's lead in taking away that functionality.

To me that's like designing a car that can't make left turns. It actually would be safer -- a lot more accidents occur making left turns than right turns, and the fatality rates are much higher. Also, there's a workaround: You can just make three right turns to go left. So why not just do away with left turns -- and to force the issue, let's take that ability away from cars because left turns are bad design. And if there are some places where those cars simply can't go, well, that's the cost of doing things right.

Meh. It is what it is, and it's easy enough to fix on the design end. I'm just becoming a curmudgeon is all.

-Rich
Seems like they made some pretty successful decisions given the fact that they single handily actually made the first viable tablet with real growth after many companies failed time and time again trying in the past.
 
Back
Top