The Future of FSS

Wed Sep 25 15:17:19 UTC 2013

I've started a wiki page to help gather our thoughts.
http://wiki.fluidproject.org/display/fluid/Post-FSS+Planning

Add your notes to that wiki page and hopefully it'll help us in our
research.

On Wed, Sep 18, 2013 at 10:11 AM, Colin Clark <colinbdclark at gmail.com>wrote:

> Great! This is work for Infusion 2.0, which we don't have a formal date
> for yet. The plan is to release 1.5 (the last of the 1.x line) in the next
> couple of months. From there, we'll likely release a couple of 2.0 beta
> releases before cutting 2.0 final sometime in the next year.
>
> So we've got lots of time. :)
>
> Colin
>
> ---
> Colin Clark
> http://fluidproject.org
>
> On 2013-09-18, at 10:06 AM, Johnny Taylor <johnny at abledaccess.com> wrote:
>
> > Hey,
> >
> > I'd like to get in on this, too. But I haven't a lot of time to dedicate
> to much extra-cirriculuar activities at the moment. What kind of timeline
> were you looking at?
> >
> > Johnny
> >
> > On 2013-09-18, at 9:54 AM, Colin Clark <colinbdclark at gmail.com> wrote:
> >
> >> 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
> >>
> >> _______________________________________________________
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130925/7292f89e/attachment.htm>