The Future of FSS

[Colin Clark]

Hi Jon,

Thanks! That's awesome. It'll be a fun project.

Colin

---
Colin Clark
http://fluidproject.org

On 2013-09-18, at 9:11 AM, Jonathan Hung <jhung at ocadu.ca> wrote:

> Hi Colin,
> 
> Thanks so much for bringing this back to the top. Glad to hear that FSS is going to get some attention going forward.
> 
> I'd be willing to initiate / facilitate the research into 3rd party tools if no one else steps forward. I imagine others will have input on this as well.
> 
> - Jon.
> 
> 
> 
> On Tue, Sep 17, 2013 at 10:57 AM, Colin Clark <colinbdclark at gmail.com> wrote:
> Hi all,
> 
> There hasn't been any activity on this thread in two months, so I guess we don't have a huge wave of creative ideas for the future direction of FSS.
> 
> We're planning to significantly refresh and simplify Infusion for version 2.0, which we will likely release within a year. Now seems like the time to start deprecating aspects of Infusion that we aren't planning to bring forward with us.
> 
> Here's my proposal:
> 
> 1. Deprecate the FSS in Infusion 1.5. We'll continue to support it fully until we have a viable replacement.
> 2. Start a research effort to look at third-party CSS tools, selecting one that we will use in UI Options as well as for our demos
> 3. Ship this new third-party tool and any additional supports needed by Infusion users in version 2.0
> 
> Thoughts and comments? Is there anyone who is willing take a lead on #2?
> 
> Colin
> 
> ---
> Colin Clark
> http://fluidproject.org
> 
> On 2013-07-03, at 3:08 PM, Colin Clark <colinbdclark at gmail.com> wrote:
> 
> > Hi Jon and everyone,
> >
> > On 2013-07-03, at 10:24 AM, Jonathan Hung <jhung at ocadu.ca> wrote:
> >
> >> Recently Justin, Heidi, and I have been talking about FSS and we were wondering if we should continue maintaining FSS or transition to a new strategy.
> >
> > Have you considered what the alternative strategies might look like? If so, could you describe them for us?
> >
> >> Specifically, it seems that browser standards compliance, third party CSS frameworks (like Twitter's Bootstrap), and CSS languages (like Sass/SCSS, or Less) have advanced sufficiently that it could replace FSS. However, if we make a change to using a CSS framework, this will affect other Infusion components like UI Options.
> >
> > Can you elaborate on how these different technologies might serve as a replacement for FSS? What roles would they play, specifically? We've got some very diverse tools listed here--Sass is quite different from, say, Bootstrap, and works at a lower infrastructural level. Can you guys describe how you imagine we might use these technologies?
> >
> > Johnny Taylor seems incredibly enthusiastic about Sass, which is a good sign.
> >
> >> Conversely, maintaining FSS is complex due to:
> >> - the different theme implementations (FSS comes with 10 themes)
> >
> > My impression is that most of the "demo" themes--rust, mist, etc.--are long overdue for being deprecated and removed. The themes used by UI Options, however, are foundational for doing transformation of web applications. Are you thinking that we'd replace these with something else, somehow?
> >
> >> - the FSS CSS itself is like the API (modifications must be done with consideration to the effect on end users)
> >
> > I'm not sure I understand what this means. Can you explain?
> >
> >> - lack of resources to maintain and improve it (some styling methods used in FSS seem a bit antiquated like using .PNG images to create different button borders for themes).
> >
> > Yes, I agree. I've tried to encourage efforts to address these legacy weaknesses in FSS, but so far no one has been willing to take on the job. Given that, I'm not averse to simply choosing an existing framework (Bootstrap, Foundation, or one of the many, many others out there) and offering it up both for our own development and for our users.
> >
> >> Do we:
> >> 1. maintain status quo (no changes)
> >
> > I don't think this is a good idea to maintain the status quo for FSS, but we do need someone who wants to take on and lead a renewal effort.
> >
> >> 2. explore re-implementing FSS using another framework like Bootstrap (and keep FSS classnames the same)
> >
> > I think we will have to consider how to preserve backwards compatibility, especially for UI Options users who have sprinkled FSS class names throughout their apps. We could certainly consider streamlining the class naming conventions we use (they're pretty long), but I think we do also want to support the use case where people are mixing up framework classes with their own. Most CSS frameworks that I've encountered tend to use unprefixed names that will cause conflicts with many existing stylesheets, which is a shame.
> >
> >> 3. deprecate FSS
> >
> > Presumably we still need something to power UI Options, so I'm not sure if this a viable option. Or am I missing something?
> >
> > I hope this helps,
> >
> > Colin
> >
> > ---
> > Colin Clark
> > http://fluidproject.org
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> 
> 
> 
> -- 
> JONATHAN HUNG
> 
> INCLUSIVE DESIGNER, IDRC
>  
> T: 416 977 6000 x3951
> F: 416 977 9844
> E: jhung at ocadu.ca
>  
> OCAD UNIVERSITY
> Inclusive Design Research Centre
> 205 Richmond Street W, Toronto, ON, M5V 1V3
>  
> www.ocadu.ca
> www.idrc.ocad.ca