Ruby on Rails and Web sites that won’t work on the T-Mobile Sidekick

by philg

My Motorola/Windows XP phone began to die after two years. Wanting something that would let me keep in touch with friends over AOL Instant Messenger, I got a T-Mobile Sidekick. I was reluctant to get a non-flip phone, but so far I have only managed to make one unintended phone call per day. The Web browser is excruciatingly slow. I’ve found that most of the Web sites developed in the early 1990s work just fine. It is possible to log in, fill out forms, get results. What doesn’t work? The latest and greatest Web sites. They are too script-heavy. Programmers seem to have forgotten that although the average desktop has ever-greater capabilities, the average user is increasingly connecting from a handheld device. I tried using one of my students’ sites from last semester. They lifted some username/password code from a Ruby on Rails toolkit. It relies on JavaScript. The site is 100 percent useless from the Sidekick.

Have we proven that “the better the tools the worse the application?”

21 thoughts on “Ruby on Rails and Web sites that won’t work on the T-Mobile Sidekick”

  1. Phil,

    I use a free service called IYHY.com on my SideKick II. It converts sites to text-only and works very good. Therefore I was able to add another few sites! You would also be amazed how many complex sites still offer text-only or mobile editions.

    Also, Bloglines.com as RSS feed-reader works perfectely.

    Cheers,

    Lo

  2. Mobile devices suffer the same problem that mac browsers did a few years back, they are such a small part of the market its not worth dumbing down the site for 1% or less of your users. (Spoken as an avid Mac and mobile user)

  3. I’m not familiar enough with Ruby on Rails to know whether it supports what are referred to “unobtrusive” JavaScript techniques, the basic idea of which is to first get the site working without any script, then attach scripts in a way that will only be visible to the clients which support them. More on this, and also a nifty server-side supplement:

    Ten good practices for writing JavaScript in 2005
    http://www.bobbyvandersluis.com/articles/goodpractices.php

    Make Your Site Mobile-Friendly in Two Minutes
    http://www.mikeindustries.com/blog/archive/2005/07/make-your-site-mobile-friendly

  4. Chances are that you just aren’t the audience of those websites; if the websites you visit give you problems, they probably just don’t think the audience of mobile users is big enough.

    The web is growing, standards are accepted. People start using features which enable great things; think about AJAX for example. Sure, this might not work on a mobile device, but it isn’t supposed to. The web browsers on people use behind their PC’s set the standard, and if other devices want to compete, they should follow that standard; if they cannot reach that standard, the problem lies with the devices, not the websites.

    If the problem really was that bad, the websites you cannot visit would get into financial trouble and they would have to adapt. I don’t see them in any problems right now, so I don’ think it really is a problem.

  5. Better tools simply make it easier for people who are incompetent, or at least not competent enough, to build sites that work… sometimes. The problem is not the tools. The problem is the people using the tools.

  6. I think we’ve proven that nothing has changed. Handheld web-browsing technology has consistently lagged behind desktop browser functionality.

    Back when all websites were “basic” HTML and web forms, phones by and large still weren’t up to the task of showing them. People had to create mobile versions of their UIs if they wanted to deal with limited WAP-based phones, or handhelds that weren’t constantly online, or phone browsers that did some serious page reconstruction to render on a small screen (especially since most layouts were done with tables).

    Now *some* phones have caught up to the task of reading basic web sites, but browsers have taken another step forward (ex. AJAX), and phones are still a generation behind. We’re still at the point where, realistically, you have to create 2 versions of your site (at least the view layer) to provide the best possible experience to phone users and PC users.

    The more things change, the more they stay the same.

  7. JavaScript and client-side scripting in general is a plague on the the Internet. It is the source of thousands of lines of unstructured speghetti code and slow web sites. And Ruby on Rails is not a substitute for a platform that is optimized for mobile devices, like mobile.NET.

    How many times do you see the little JavaScript error icon in IE? The scripting oriented nature of raw Ajax doesn’t help matters, it just means that more programmers can fool themselves into thinking they can build robust websites because they lifted some code from another website and got a HelloWorld page working. The OpenSource movement also impacts this experience — now anybody can download a compiler and a MySQL database and start hacking out code in Notepad. Not that this code will ever be maintainable or scalable. I am getting a lot of calls from disgusted clients wanting me to bail them out because they hired some kid who promised them a cheap ecommerce site using things like PHP and MySQL, only to get bogged down by the weight of thousands of lines of scripted code and non-normalized data.

  8. Rails forces a proper Data/Model/View structure on the program and has easy hooks to develop alternate views and REST APIs. If the students coded well they should be able to hook up a non-Javascript login and mobile-friendly views in very little time.

    There is absolutely no enforced use of Javascript anything in Rails. Your students simply lifted the wrong snippet of code.

    For a fascinating look at how to leverage Rails for mobile and mashup check out 37signals’ Backpack product. It has a mobile view and APIs for Perl, Ruby, PHP — along with a well-documented way to make your own APIs so that you can do whatever you want with the application.

  9. Actually, I think you have proven that you bought the wrong device 😉 The Siedekick is well known for its limited browsing capability. There are other, much more powerful smartphones on the market. You should have taken a look at some Symbian S60 based phones, such as the Nokia E70 or E61. There are several instant messaging clients available (check out http://www.agilemobile.com/agile_messenger.html) and the browser is based on Apple’s Safari. And yes, it does support Javascript.

  11. I don’t think it is Ruby’s fault. After all Ruby on Rails is purely server side, but the Web 2.0 hype leads to use JavaScript and AJAX-like techniques. Sometime to abuse them.

    As for mobile web devices, the only one I have found worthwhile for browsing in the Nokia 770, but it is not a phone. However you can use it over GPRS or whatever you can access as a “modem” from your phone over Bluetooth. That makes 2 devices but one of them can be very small.

  12. I use my Treo a lot for mobile web browsing, which I would imagine is similar in capabilities to the Sidekick. Web developers do need to realise that more and more mobile devices will be being used. So many sites are so bloated these days, it’s not even funny…

    Some great mobile websites :

    http://news.bbc.co.uk/text_only.stm
    http://mobile.wunderground.com/
    http://www.otweb.com/pda.html
    http://www.google.com/pda (Regular http://www.google.com is also good).

  13. The fact that the Sidekick can multi task so well means that even if a website is loading slowly, you can be doing email, chatting on IM, checking your Calender, writing a text message all while it loads in the background.

    Congrats on getting a good device. The keykboard on the Sidekick 3 is the most usable of any PDA I’ve ever tried, and multi tasking on the Sidekick 3 simply rocks. I even tried a Blackberry previously and it was not as good.

    You might want to check out

    http://www.hiptop.com/forums

    which is the online community for all things Sidekick.

  14. I seem to remember how I couldn’t get into ACS-based website in 1999 because my browser could not save cookies. Websites with ugly browser-based login windows (apache .htaccess etc.) were OK.

    Was ACS also a sort of “grand tool” of its time?

  15. I’m not up on the capabilities of modern web browsing phones but..you mentioned that one of them had XP under the hood….

    Is there a Windows remote desktop client available for the phone you’re now using?
    I do nearly all my out-of office work and browsing via remote desktop these days….why maintain several desktops, favorites, settings files, purchase apps, etc, when you can have your desktop with you anywhere in the world?
    (just don’t stream video 🙂

  16. It’s just the main reason for developing Mobile 2.0. My suggestion is to use a two-display solution as a standard hardware platform and divide the core content of a Web site for the better presentation on the main display and its framework – menu and the ads – for navigating on the second display-keyboard and easily access to the banner advertisements for consumers.

    Cell Computer Project

    http://geocities.com/gene_technics

    Regards,

  17. Mobile phones improve every year. By the time you got your entire web2.0 site dumbed down so it works on a mobile phone the phones would have progressed to the point you didn’t need to in the first place.

  19. According to Firefox Quick Find, the words “degrade gracefully” haven’t shown up in the thread, so here goes: degrade gracefully.

    There are plenty of ways to use JavaScript without requiring it — for instance, your “edit item” link can being up a page with an edit form in old browsers, and generate the form inline on new ones. There are economic incentives against coding and testing that functionality — the real solution is to bake graceful degradation into your frameworks; the same code that builds an inline form with JavaScript can spit out the same form as a standalone page from the server. Perhaps if you do the hard work of building the framework now, you, yes you, will be the new hottness when downlevel mobile browsers get more popular. (Or perhaps mobile browsers will skip a couple grades and go straight to being webapp-capable!)

  20. I share in your frustration. I hope that the new .modi domain names address the issue. I have to hope that companies that are smart enough to register these domains are smart enough to only use lighter more compatible technology when implementing the sites.

Comments are closed.