[LRUG] Best practices for reskinning / redesigning the look and UI of a Rails app?

Fri Mar 18 21:39:57 PDT 2016

I've a small internal gem I use that renders a 'components' page and anything it finds in a wireframe view folder. 

The components page has all the standard elements, dummy forms with element states like required or error. 

I then go through the new design extract and hopefully rationalise all the components used in the new design. 

Then build the components page in a new layout and any big re-designed or new pages into the wireframe folder. 

Then cutover is relatively easy, piece by piece. 

The side benefit is you end up with a style guide for any future changes. And I often find several things get killed or standardised out. 

J.

Sent from my iPhone

> On 19 Mar 2016, at 02:18, David Salgado <david at digitalronin.com> wrote:
> 
> We've had some success using variants in Rails 4 to reskin an app using material css.
> 
> We created a new layout called "material" for the new variant, which loads CSS from a different assets sub-directory, then we could create index.html+material and it would be rendered with the new skin. The nice thing is that the old views render without any extra effort, if there isn't a new version available. So it makes it quite easy to do a gradual re-skinning.
> 
> http://edgeguides.rubyonrails.org/4_1_release_notes.html#action-pack-variants
> 
> David
> 
> 
> 
> 
>> On 18 March 2016 at 17:11, Priit Tark <priit at gitlab.eu> wrote:
>> Hi,
>> 
>> I have done new redesign implementation for heavy use live site where it wasn't possible to upgrade everything at once because some parts needed ground up rethink and more time than some other parts.
>> 
>> In some period of time we used even dynamic layout switch depending on context/user.
>> 
>> For development clarity, we gave distinct name for a new layout such as 'ui2'. This way you can prefix some already upgraded partials with 'ui2_' without messing up old user interface components and partials.
>> 
>> It work for us well upgrading step-by-step with group of controller without any big mess.
>> 
>> Kind Regards,
>> 
>> Priit Tark
>> Lead Developer
>> 
>> Gitlab Ltd 
>> http://gitlab.eu
>> Ticketing 
>> http://tikitur.com
>> 
>> 
>> 
>>> On Fri, Mar 18, 2016 at 5:34 PM, Jesse Waites <jesse.waites at gmail.com> wrote:
>>> Thanks Jon, that sounds like a great approach. 
>>> 
>>> I was also thinking about firing up a new rails app, literally "rails new prototype", and building the views I want onto a clean slate, then transferring everything over to the new rails app once the HTML is in place, rather than writing new HTML on top of old HTML and having a spaghetti type situation on my hands, with new and old HTML everywhere and CSS classes conflicting with each other all over the place. Anyone have thoughts on that approach?
>>> 
>>>> On Fri, Mar 18, 2016 at 11:15 AM, Jon Wood <jon at ninjagiraffes.co.uk> wrote:
>>>> We've been through that process a could of times at Hubbub now. For our latest revision we rebuilt the entire customer facing website from the ground up as an API client - it was the right move, as it killed off a lot of technical debt that had grown over the years, and allowed us to completely rethink how customers approach the site. However, its a bit drastic, so I'll write about the first time round when we just rebranded without any major changes to the UX.
>>>> 
>>>> As you say, branch first, nothing is going to be pretty for a while. After that we started by rewriting our application layout to use the new framework, and introduce the new design to any global elements on the page like navigation and sidebars. That also involved reworking a lot of partials that made up those elements. The key thing here was to start afresh with CSS which allowed us to avoid having two frameworks conflicting with each other.
>>>> 
>>>> At this point the entire site was hideously broken in the most literal sense. Now begins the gradual process of updating every view in your application - hopefully its been built with some sort of reusable components in the frontend which will make this easier, but ultimately you're going to be reworking a lot of CSS classes.
>>>> 
>>>> Once that's done, its time for some pretty extensive testing. We ran a beta period where we slowly rolled the new design out, first to staff, and then to some of our more friendly customers.
>>>> 
>>>> Something we didn't get the chance to do, and I wish I could remember the name of the tool, was to run the entire site through a tool which can pick up any unused CSS classes in the HTML, and find any unused CSS definitions. If you've got decent integration test coverage it should be enough to run your suite of tests and see what that brings up.
>>>> 
>>>> Hopefully that's of some help - I'm working from memories of something we did in 2013, so its a bit rough!
>>>> 
>>>> Jon
>>>> 
>>>>> On Fri, 18 Mar 2016 at 14:56 Jesse Waites <jesse.waites at gmail.com> wrote:
>>>>> Hello everyone,
>>>>> 
>>>>> I've recently started a new job and one of my first orders of business is to reskin the app. It basically looks like hot garbage right now and my boss wants me to redesign it with a proper framework, etc. I am also looking forward to this because I have a pretty good design eye and it will be cool to have complete ownership of the look and feel of a production web app.
>>>>> 
>>>>> I have started with making some general UI mockups in Balsamiq and have approval to implement this design from upstairs. 
>>>>> 
>>>>> I suppose I will simply create a new branch and start adding the framework, and start redesigning this maybe a controller at a time, hitting each view in each controller? That seems like a reasonable approach to me.
>>>>> 
>>>>> I know how to technically do this but I'm curious about the best overall strategy to reskin (Add a new front end / UI) a rails app. If someone has done this before and wouldn't mind writing about their process / best practices for something like this, I would appreciate it.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Jesse Waites
>>>>> JesseWaites.com
>>>>> _______________________________________________
>>>>> Chat mailing list
>>>>> Chat at lists.lrug.org
>>>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>>>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>> 
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org
>>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>> 
>>> 
>>> 
>>> -- 
>>> Jesse Waites
>>> JesseWaites.com
>>> 
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> 
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20160319/ec211899/attachment-0002.html>