I'm building a new front end for an existing forum project, and I'm undecided on the best route to take for the user front end. The project will be built in ASP.Net 3.5.
The requirements are as follows:
1) User selectable themes/templates must be supported - I have forum goers who will want to contribute forum themes, so the layout system must be flexible.
2) Mobile friendly. The site must be usable from the most popular mobile browsers, so I have to be able to substitute templates based on the user agent and/or site url.
As near as I can tell, these are my best options:
1) XSLT: Output all of the relevant data in XML format, and dynamically attach an XSL stylesheet based on user settings/mobile state. I'm unsure how well mobile browsers support XSLT, but it appears that at least some do.
2) MVC: Sub in a different view based on user settings/mobile state. This might be harder to support templates from users, however.
3) Pure CSS: Standard DIV+CSS style layouts, subbing the CSS stylesheet in based on user settings/mobile state.
I'm quite sure that all of these options will work, however, I have only a basic familiarity with MVC, having developed exclusively in WebForms until now.
I'd love some guidance here, before I end up down the wrong path.
I would go for pure CSS layouts. It is increasingly being supported by more and more browsers.
I can't comment on MVC - no experience with that.
XSLT is something I like a lot. I don't know about mobile browsers, but it certainly is well supported by major desktop browsers (by supported I mean XSLT 1.0 is well supported). The downer is that there seem to be relatively few people with skills - much less so than CSS. So if your goal is to get reasonable abount of user contributed themes, I think that would be much better achieved with CSS.
Related
As a way of raising the standards of our codebase I would like all new web projects (where possible) to use MVC5 with Inversion of Control. I'd like to have a service, domain and repository layers. Plus Unit Tests to get them started.
Obviously this is a lot of code to do up front for every project, and I want to avoid "just copy ProjectXYZ and strip out what you don't need" as this has been fraught with human errors in the past.
How do I take my very basic skeleton solution and turn it into a template for my colleagues to do File -> New Project etc ?
They could just copy the .sln I create, but it seems like there might be a more professional way to do it.
Perhaps there is already one out there we can use?
I am the developer of ASP.NET MVC Boilerplate (I found this question by checking my GitHub traffic and seeing #floatas's link, so thank you #floatas).
The default MVC project template is too basic and gives you very little out of the box. The idea behind ASP.NET MVC Boilerplate is to write all the boilerplate code for you, so you don't have to.
Now it does not contain unit tests, repositories etc. but it does include a lot of other things that every website requires.
Secure By Default
The default MVC template is not as secure as it could be. There are various settings (Mostly in the web.config file) which are insecure by default. For example, it leaks information about which version of IIS you are using and allows external scripts to access cookies by default!
ASP.NET MVC Boilerplate makes everything secure by default but goes further and uses various HTTP headers which are sent to the browser to restrict things further.
It also makes use of the new Content Security Policy (CSP) HTTP Header using the NWebSec NuGet packages. CSP revolutionizes web security and I highly recommend reading the above link.
Setting up SSL/TLS, so that your site runs over HTTPS is made easy with easy step by step instructions and links.
Fast By Default
The default MVC template does a pretty poor job in the performance department. Probably because they don't make any assumptions about which web server you are using. Most of the world and dog that are writing ASP.NET MVC sites use IIS and there are settings in the web.config file under the system.webServer section which can make a big difference when it comes to performance.
ASP.NET MVC Boilerplate makes no such assumptions. It turns on GZip compression for static and dynamic files being sent to the browsers making them smaller and quicker to download. It also uses Content Delivery Networks (CDN) by default to make common scripts like jQuery quicker to download (You can turn this off of course but the point is ASP.NET MVC Boilerplate is fast by default).
That's not all! There are a bunch of other tweaks and examples of practices which can help improve the performance of the site. ASP.NET MVC Boilerplate achieves a score of 96/100 on YSlow (Its not possible to get the full 100 as some of it's criteria contradict each other and site scripts need to be moved to a CDN which you need to do yourself).
Search Engine Optimization (SEO)
The default ASP.NET MVC template takes no consideration of Search Engine Optimization at all. ASP.NET MVC Boilerplate adds a dynamically generated robots.txt file to tell search engines which pages they can index. It also adds a dynamically generated sitemap.xml file where you can help search engines even further by giving them links to all your pages.
ASP.NET MVC has some very useful settings for appending trailing slashes to URL's and making all URL's lower case. Unfortunately, both of these are turned off by default, which is terrible for SEO. This project turns them on by default.
It also includes an MVC filter which helps to redirect non-canonical URL's (URL's without a trailing slash or mixed case characters which are considered different URL's by search engines) to their canonical equivalent.
Accessibility
4% of the world population is estimated to be visually impaired, while 0.55% are blind. Get more statistics here. ASP.NET MVC Boilerplate ensures that your site is accessible by adding aria attributes to your HTML mark-up and special shortcuts for people using screen readers.
Browser Compatibility
Websites need to reach as many people as possible and look good on a range of different devices. ASP.NET MVC Boilerplate supports browsers as old as IE8 (IE8 still has around 4% market share and is mostly used by corporations too lazy to port their old websites to newer browsers).
ASP.NET MVC Boilerplate also supports devices other than desktop browsers as much as possible. It has default icons and splash screens for Windows 8, Android, Apple Devices and a few other device specific settings included by default.
Resilience and Error Handling
At some point your site is probably going to throw an exception and you will need to handle and log that exception to be able to understand and fix it. ASP.NET MVC Boilerplate includes Elmah, the popular error logging addin by default. It's all preconfigured and ready to use.
ASP.NET MVC Boilerplate uses popular Content Delivery Networks (CDN) from Google and Microsoft but what happens in the unlikely event that these go down? Well, ASP.NET MVC Boilerplate provides backups for these.
Not only that but standard error pages such as 500 Internal Server Error, 404 Not Found and many others are built in to the template. ASP.NET MVC Boilerplate even includes IIS configuration to protect you from Denial-of-Service (DoS) attacks.
Easier Debugging and Performance Testing Tools
ASP.NET MVC Boilerplate makes use of Glimpse (As advertised by Scott Hansleman here). It's a great tool to use as you are developing, to find performance problems and bugs. Of course, Glimpse is all preconfigured, so you don't need to lift a finger to install it.
Patterns and Practices
Doing things right does sometimes take a little extra time. Using the Inversion of Control (IOC) pattern for example should be a default. ASP.NET MVC Boilerplate uses the Autofac IOC container by default. Some people get a bit tribal when talking about IOC containers but to be honest, they all work great. Autofac was picked because it has lots of helpers for ASP.NET MVC and Microsoft even uses it for Azure Mobile Services.
ASP.NET MVC Boilerplate also makes use of the popular Less files for making life easier with CSS. For an example, it can make overriding colours and fonts in the default Bootstrap CSS a cinch.
ASP.NET MVC is a complicated beast. You can end up with lots of magic strings which can be a nightmare when renaming something. There are many ways of eliminating these magic strings but most trade maintainability for slower performance. ASP.NET MVC Boilerplate makes extensive use of constants which are a trade-off between maintainability and performance, giving you the best of both worlds.
Search
There is a lot more to implementing search in your application than it sounds. ASP.NET MVC Boilerplate includes a search feature by default but leaves it open for you to choose how you want to implement it. It also implements Open Search XML right out of the box. Read Scott Hanselman talk about this feature here.
Social
Open Graph meta tags and Twitter Card meta tags are included by default. Not only that but ASP.NET MVC Boilerplate includes fully documented HTML helpers that allow you to easily generate Open Graph object or Twitter Card met tags easily and correctly.
There is RehanSaeed/ASP.NET-MVC-Boilerplate, aspnetboilerplate.com and probably many more tools to generate starting template. They are open source and can be installed as a plugin, so you can change the way you like and give to your team.
If you still really want to create your own, you can follow these steps. I can't include them all here because they are quite long.
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've read the Sencha Touch docs. I feel its MVC model is very attractive but it seems to has a long start-up time, especially with external JavaScript (eg:map).
Although I'm comfortable using jQuery in a web site, I have concerns about the maturity of jQuery Mobile. (I haven't tested it yet)
I have no idea about Dojo's mobile framework.
Which of these alternatives do you like? Why?
So what exactly are you requirements? Each framework has different several advantages and disadvantages....
Me personally I use Jquery Mobile, which is now at it's first official release. Don't let version numbers fool you, this has been developed 1 year long and actually works pretty good!
The others provide different capabilities:
sencha is based on javascript controls - you create the whole layout from within javascript using JSON notation for properties/actions/events
jqm allows you to use your "standard" HTML and enhances it "auto-magically". In my opinion this is the closest to HTML you'll ever get
Dojo is more about MVC and allows a more structured environment. Haven't used it personally so I can't say too much about it...
Hope this helps
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/
There are a few pages here addressing usage of jQuery with .net masterpages - fewer re: masterpages in MVC in .net MVC apps. But those few seem to be making distinctions re pre-release versions of MVC.
Is there now a consensus regarding how and where to include the lib and what potential problems we need to be aware of?
It _looks as though things are fairly straight forward...put the include in the masterpage's head and stuff works. (as it has for me _so far). I guess I'm looking for lessons learned and what to watch out for - i haven't scratched features like partial views and ajax yet.
thx
As Iconic mentioned, you're free to use jQuery however you see fit. I would decide this after planning my site - if only a page or two are using jQuery, I would include it in them only. If my whole site relies on it (like SO does, for example), I would include it in my masterpage. All it takes is a simple tag, and the only thing to watch out for is perhaps some bandwidth, if you expect to have much traffic to only several pages, which does not use jQuery.
There's no magic way to include jQuery. Since it's a client-side library, including it in the master page makes it easy to hook into $(document).ready from any view or partial view.
Once it's at the top of your page, it's trivial to include plugins or hook into events at any point. That way, you can encapsulate jQuery that is specific to your application in the view or partial view itself.