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.
Related
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/
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that
I'm in the process of planning out a site for a friend, they need to be able to modify site content, have a products section and shopping/ check-out area. All the products need to be able to be updatable too (descriptions, photos, cost - including delivery, etc).
As I'm a bit of an ASP.NET MVC fanboy currently, I was going to build a quick CMS in my spare time, however, a friend just pointed me at WebQuarters - an open source MVC based CMS.
So, my question is this - given the requirements, does it make more sense to build on top of WebQuarters or go my own route?
Additionally, does anyone have any experience of using WebQuarters...is it any good or should I steer clear?
Thanks,
Kieron
I've been looking at this as well and trying to see how suitable it will be for a similar project I will be starting soon. So far it looks good, but some of the admin parts when your editing your pages don't feel quite as solid (like editing the menu order).
I'm keeping an eye on it though, I think it will be a great library to add to your tool chest.
I've been asked to devise a website for a small organization (with limited funding) - with internal and external facing sides.
Internally it would allow sharing of documents, a blog, goal setting, more?
Externally it would provide a simple but nicely designed public statement about the company's services.
It may evolve over time.
Should this be a custom-built solution or does it make more sense to ride on top of a platform that provides this type of service (such as?)?
If it's a custom built-solution, I'm considering doing this in Rails - would there be something like this already built for Rails?
I've always found it frustrating to build on top of pre-existing platforms, especially when it comes time to extend the functionality. If it's up to you, I'd suggest to build it yourself. Pick a framework and design specifically around the needs of the company.
Rails is a nice choice if you're comfortable programming Ruby. Although, any modern MVC framework would be just as good.
I'm quite a big fan of Hobo. Sits on top of and extends Rails. Provides a lot of standard scaffolding, an admin function and section, and lets you publish static pages. You can stick a "before_filter :login_required" on any and all controllers to prevent random visitors from seeing things, or extend the user model to have role or other based access controls.
I've never used Hobo to fully build out a scaled service for more than a handful of users. But in a small environment, it's awesomely fast to put together resources, with access controls.
Django has an amazing admin function already built into the framework. It could potentially take care of all of the internals, and the external view can be shown to anyone who doesn't navigate to the admin.
It's at least one consideration if you're thinking of making a custom solution (which I might suggest if you believe the site will most likely grow.)
Depending on your resources, I would start off with an "as-is" solution that allows customization. This will give you the quickest "wins" from the company standpoint. Once the organization, and you, start to use and understand the benefits, you can start customizing pieces.
Depending on your budget Windchill does this. I believe it was once called GlobalVault (a much better, and more descriptive, name).
Any thoughts on using Flex to build an RIA for administering a complex rails app?
We are starting to find it difficult using ajax to keep our admin section intuitive and easy for users to work with.
You've got RoR guys working on this program and you've managed to develop a complex rails app that has enough subtleties that the admin section is difficult to use.
The answer to this problem is not to use a different programming language to create a whole nother kinda app to do the admin.
It will help more to get assistance in simplifying and organizing your admin section. Work through some paper sketches to get a better idea of how to present this complexity and maybe reveal complexity as you go along.
Complexity is handled often by using wizards or revealing suboptions as you go along. Spend some time with your users and watch them do their tasks.
With more details I could edit this answer with more specifics.
Try investigating this book:
Flex is certainly worth considering in your scenario. Generally, Flex is more mature development platform than AJAX is so if your server-side data are exposed via some reasonable interface (web services, REST-full services etc.), building a Flex front-end would make sense.
It really depends on your needs - Flex vs. AJAX is an interesting topic on its own.
If you want to use XML for communication then there isn't much you need to do on the rails side. But if you want to use an AMF gateway you will want to checkout RubyAMF.
But I agree with MattK if you just want to redesign your admin section it's not worth adding in Flex. I think you just need to do some usability testing, take that feedback and refractor your interface.
I would only consider using Flex in your situation if you already have Flex developers or if you could outsource that part of your project. The Flex modules simply call web services (written in Ruby or whatever) so there is a very nice separation between the two parts of your project. Since the interface between the two parts is an easily-mockable web service, outsourcing works well. There should be plenty of web shops local to you who could handle the work. An admin site should take only two to three weeks to develop in Flex if the developers are knowledgeable.