This post has been 'somewhat' addressed (see links at bottom of post) but not to it's full extent.
I am working on building a mobile site in Rails 2.3 (I know, I'm going to migrate to Rails 3 soon). Either way, as I continue developing this mobile site (and I am using Mobile Fu - works great), I'd like to understand best practices around configuring and managing the mobile site:
Where should I redirect to the mobile domain (in application controller)? What is the best logic for doing this?
Should I build the .mobile.erb files in the same folder as the .html.erb files? Or in a separate mobile folder?
What kind of routes/controller/etc logic do I need for my mobile site (if I decide to not embed the mobile rendering inside my current application structure, but instead have a separate controller and mobile view folder)?
I appreciate it.
Other links:
Web and Mobile views best practices same controller or namespace?
http://www.arctickiwi.com/blog/mobile-enable-your-ruby-on-rails-site-for-small-screens
Rather than answer your question directly, I am going to suggest that best practices have moved on somewhat.
Concepts like Mobile First, Adaptive Design, Responsive Design, and Progressive Enhancement are replacing the split site approach as best-practice.
These concepts revolve around building out your site for mobile first (so you can work out what the most important things are) and then extending the design for screens that are larger.
It removes the need to determine if it is a 'mobile' accessing the site and instead relies on various techniques (adapt.js or CSS media queries) to target different layouts to the variou screen sizes. It also means you do not have to maintain multiple views and routing - you have one view and change the CSS.
When you move to Rails 3.1 (with the pipeline) this allows the creation of CSS (and JS) manifests, and you can (potentially) have one manifest for each screen size.
There are issues with the above approach (just as there are with split sites), but if you Google the key terms above you'll find tons of advice. Best of luck either way!
Edit: Here are some links I found useful.
http://www.lukew.com/ff/entry.asp?933
http://www.netmagazine.com/features/mobile-first
http://www.alistapart.com/articles/responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
http://www.alistapart.com/articles/taking-advantage-of-html5-and-css3-with-modernizr/
http://www.sitepoint.com/regressive-enhancement-with-modernizr-and-yepnope/
There are some that think that this is bad though:
http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-modernizr-inadequacy/
Related
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I'm making a board game in rails, and was considering using backbone.js (or a competing library) to handle the gameplay page and manage all of the models and the UI. Is it useful for something like this (over just making my own classes)? Or is it really only worth it for making a single page app? I've read a bit about the library, but I can't tell if its features will help simplify what i'm trying to do or if they are just overkill for a single page.
Yes, Backbone can handle this perfectly. 37signals, for example (founded by Rails's creator DHH) uses Backbone for the calendar, but not on the other pages.
I have a site that's done using ASP.NET MVC and jQuery. Is it possible to modify my existing project without too much of rework so that it can be used in phonegap to create iphone/android apps?
Here's an approach: move your logic to an MVC WebAPI (or other REST/webservice) project, then convert the MVC site into a simple html/javascript/css/image site (Mobile site). Then refactor your Mobile site to use Ajax/JS to query the WebAPI/Rest services you created. Once you've separated your code this way, you can then package the Mobile site with Phonegap. I'm not sure how much work that will be for you or your project. If you're using a lot of Html Helpers or Razor markup in your views it may be too involved.
The core point of my suggestion here is to separate your mobile UI layer and the backend processing layer so you can only package the Html5/UI/Javascript layer with Phonegap and leave the backend processing on your web server. I don't think I need to explain this, but obviously the app packaged with Phonegap is not going to have the MVC/.Net framework available on the mobile device to render views or execute controllers, etc. By migrating your UI to be simple Html5 and Javascript you can use Ajax/Jquery/Javascript calls against your backend, which you will probably want to host in ASP.Net MVC WebAPI.
Edit: Guess there was some confusion about my suggestion. I'm not saying this is the only way to do go, but this is what I'm familiar with as it's how our team builds our desktop/web + mobile + phonegap + mvc4 + webapi + kendoui application. This pattern works well for us so maybe it'll work for you too, or at least give you some ideas on how to structure your solution. Good luck!
I'm not sure but you need a server to compile the ASP.NET right? so I don't think that will work for you. I think you need to work with AJAX to do your ASP.NET work and separate your ASP.NET code and your HTML-jQuery because Phonegap wants a index.html file. You can store your ASP.NET files at a server tough
The answer to your question really depends on the type of site you are trying to convert. Are you just trying to put a native framework around HTML and get your app into an app store?
If it is is mostly or entirely informational in nature and you have simply used MVC to build brochure-ware type pages then it should be fairly easy to move. This assumes that there is little to no logic other than page to page navigation.
If your site instead pushes a lot of data around that relies on a back-end server you will need to re-architect it to store data locally or pre-fetch it via a manifest. Next you will need to implement a strategy that allows you to push your local data back to the server.
Does you app need to run in a disconnected state?
Phonegap is one of the options if you want to target multiple mobile platforms & may be most widely used. Since you are using jQuery, jQueryMobile will be a least learning-curve path to use. Effort is mostly on the front-end UI and will depend on how many screens you want to design to provide a sub-set or the full set of functionality you already have on the web UI. Most likely you will have to redesign your screens using the jquery-mobile UI widgets documented here. It is also a good way to show it to your customer the initial screen design with navigation.
jquery mobile is great for learning and designing , but it's slow in the web browser control that phone gap runs in .
you'll need a more lightweight framework for this .
you can use an inappbrowser control to show your site in case it's responsive , but you wont have the device camera and contacts and so ...
take a look at : http://docs.phonegap.com/en/3.0.0/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser
I am going to create a mobile site(using Sencha touch) for an existing website. The functionalities are coded already using Ruby on Rails. If I go with adding mobile site to existing one it will make me to add conditional rendering based on the request headers or else go with creating a separate app on m.mydomain.com. I am a bit confused. Please guide me to make a decision.
I would recommend creating conditional rendering inside the existing application, primarily because you will have access to the models and utility classes within that application.
If that's a significant problem for you, you could separate out the two codebases and have the mobile site be an engine of the application, so you would still have access to the main application's classes.
I would go with m.mydomain.com and redirect the user to this automatically based on their device. T
he good thing about this is that you can have a link at the bottom of the page that is "View full website" in case the mobile site isn't what the user wants.
This also makes it easy to have separate views for the mobile site, keeping them cleaner.
I recently made a sample app that you can view on github that does something very similar. The only difference is that I am not detecting the device, I have the user visit the appropriate URL. I also used jquery mobile, but the concepts are very similar. https://github.com/jfriedlaender/mobile_blog
I've been programming for many years and have just recently got the RoR "itch". I'm thinking about how I could utilize a graphic designer and wondered how best to collaborate with them:
1) Do scaffolding and then show them where to place the graphics in the views (seems ugly)
2) Have them do screens and make them keep a certain dir structure for all media links i.e. /public/images public/stylesheets, etc. Will this confuse the graphics designer LOL?
3) Better to just have them build the images (like a header or footer image, etc.) and place them in yourself. But this approach means you have to start thinking about design and layout which seems better left to the graphics specialist.
All of the above seem flawed to me and I was wondering if there are any "best practices" for this problem? Searched for articles, etc., but didn't find much. Suggestions? Thanks all.
i work in a company that works 100% with ruby on rails development. which approach we take to integrate views.
First thing that we develop are views. The design team develop a view, tell us which data will be filled in this view and our development team develop the necessary ERB code. So normally a development process are like:
We develop some views with the client
Our dev team do the spec for functions
The design give to us the application layout
We implement it and start to work in the first models and controllers spec'ed
New whishes and views will be asked by the client, that will be sent by our design team and it will be spec'ed by our dev team.
Normally give them their own rails server, teach them the basics of where they need to add controllers and views (no need for any model stuff) to work with the default route.
I integrate the HTML, they stick in the CSS.
Teaching them how to render partials helps them with consistency. Think that's about it.