Quote:
|
Originally Posted by <b>
Personally, I dislike the automatic detection stuff. Whenever I've used that approach on sites, I get nothing but complaints from people saying that they prefer to choose for themselves whether or not to see the slimmed-down site. They don't like it forced upon them.
|
I would generally agree. However, I manage several news paper sites which people have decided to add so much crap to the home pages because they can with ease using Drupal that the performance of the normal site is behind terrible on mobiles. The mobile version at least strips out 90% of the useless blocks, views, etc only presenting the content rather than a bunch of surrounding regions which do nothing more than market other parts of the site itself and external sites. So I think it is in the sites best interest to go straight to the mobile version which is significantly less weight on the server and client than the desktop version. Working with Drupal yourself I'm sure you understand that ease and given many people including designers, marketers, etc have the ability to create panels, blocks and build sites besides install modules it is a loosing battle to take any of that stuff away.
Though really the power does need to be taken away from people who do not understand excessive amounts of views, blocks, mini panes, etc are easy to create for the layman but come at a huge performance cost. Though none of this ideal I'm sure it is a problem that other people run into with high traffic Drupal sites that expose build control to none developers which is why I think it is best to send all users to a mobile version. At least the mobile version can be easily controlled because people seem to understand that they can't just add a million things to the page because they can visually see there is no room. On a desktop though the sky is the limit because there is so much space… right.
If you are going to have separate sites though I think one of the key elements is being able to easily switch between the same pages in the different context. What I mean by that is all our story pages use a similar URL so that when someone shares something on facebook but a friend clicks on it from a mobile device they are taken to the mobile presentation of that story rather than the desktop version. It is also the same the other way around. So that is something you generally have to look out for given the nature of what a persistent URL with multiple site versions – same content, different context. Though I don't believe any of that really applies with the op. It only really applies when there are key, entity pages for products, events, stories, users, etc. At least those are really the only places that marketers care about and I have programmed the "switch" for.
Now that I have several mobile conversions under my belt using different methodologies I much prefer the the responsive approach. Though it is not always the most appropriate considering the state of the existing application. Sites that were created before semantic mark-up become important generally have to be completely rewritten anyway. At that point depending on the complexity of the site ie. surrounding "blocks" (not necessarily talking Drupal) it is better off to start fresh but merely use the same data sources. Considering most of the sites I have worked on are quit out of date created 6+ years back that approach is generally the most appropriate for projects I am assigned. Given a more time most sites created that way can become "responsive" in some sense but with past projects the sites have been too complex to make it work easily. Hopefully though with some of the next few projects when I redevelop for mobile and tear everything apart the desktop, mobile and tablet versions can be replaced wth a single, new application – finger crossed.
I say all this right now but I actually have also been using
Sencha Touch 2. Which is a very powerful for MVC JavaScript application framework for creating rich almost native like applications without page reloads. Very different from something like jQuery Mobile where you merely "hang" attributes on existing tags. In Sencha Touch 2 you develop everything in JavaScript using services to fetch data to populate views – just like you would app. Pretty neat stuff though it does have some downfalls. The major ones being it does not gracefully degrade (obviously), only works on webkit browsers at this time and it requires understanding JavaScript on at least an intermediate level I would say. Though there are plans to support *other* mobile browsers after general release (Sencha Touch 2 is in its release candidate version) – near full release but not entirely there yet. Having several months invested in Sencha Touch 2 w/ 2 projects in development would I recommend it for the op – hell no! It flourishes in building web applications that require dynamic data but for a simple small portfolio site? it would absolutely be an overkill as all separate sites seem like they would for the ops requirements.
@DeniseC
If you get your mark-up in tact (clean it up) you *might* be satisfied with slapping
jQuery Mobile on it. Personally I have had nothing but bad experiences using it myself but I work on larger, application type sites. For smaller sites though with limited time on ones hands it seems like a noteworthy solution. Though I am not very impressed by the GUESS mobile site which uses it so perhaps it just all-around sucks but to be fair guess is not really a small site.
Hybrid Mode
