-
Notifications
You must be signed in to change notification settings - Fork 14
Research: Models, Frameworks & Tools
Collection of Models, Frameworks and Tools. A more comprehensive and older list we have posted at the webDevToolKit -- here, I'm only posting projects that are contenders (can meet complex design needs, include mobile support) please post your finds, and please comment on +/-
Grid Pack (Responsive Grid Generator Tool)
Three things that strike me as promising about this tool:
-
Flexibility: as a designer I like that it thinks about grid designs from module out vs. container in approach. A weakness for flexibility of designs in those that think from the box model in is that it limits designs to pre-determined number of grids leading to awkward proportions as you size down the view port.
-
Great Scaffolding Experience: the interface is sweet; comes packed with LESS/SCSS and Jscript files
-
Open source: It's on Github ready for forking https://github.com/erskinedesign/ed.gridpak. I can't seem to easily find its copyright license terms.
Here's a background writeup: http://coding.smashingmagazine.com/2012/03/19/gridpak-the-responsive-grid-generator/
ERIC on JUNE 14
This is a cool tool for designers that want to be able to visualize a set of grid systems and then render them; however, in creating a framework, we're going to be defining the grids, so the benefits of the nice grid creator UI isn't going to be realized by end users. However, it could at least be a tool we use for rapid prototyping of our different grids.
Here's a background writeup: http://coding.smashingmagazine.com/2011/10/25/rapid-prototyping-for-any-device-with-foundation/
ERIC on JUNE 14
A negative I see to this one is no tools like LESS. This is build to be "the fastest way to prototype for all kinds of devices", but because we're designing this carefully, prototyping fast isn't really an advantage, and it's better to have something that supports development flexibility like LESS.
I do like some of their naming conventions like .columns and .six, although I'm thinking .column or .col is better - since semantically you're using the markup to be A column, not columnS.
I'm not sure I like their use of hyphens for .hide-on-phones since that's really one statement, so it should be .hideOnPhones or else .phone-hide where .phone- is a prefix. Another problem with this sort of idea is a distinction on "phones" where maybe it's better to distinguish based on some other semantic like .small-hide or .full-hide.
A productive conversation requires us to unmask the underling assumptions that each tool comes bundled with. Below are some research I have been collecting about the methodologies behind some of these tools. Please comment and weigh in on the +/- so we can consider them from all angles.
Jonathan Snook's SMACSS
A lead front-end designer at Yahoo, Snooks concerns (along with those of OOCSS) is with scalability and reuse of code in large projects. He advocates modularity and reuse with a pragmatic approach to semantics/optimization to those ends.
- The basis of Snook's CSS architecture is to abstract his CSS into logical realms by their frequency of reuse/change/volatility: base, layout, modules, state, typography (and custom skins)
- Snook's SMACSS is a methodology rather than a framework -- it teaches you some foundational principals and allows you to adapt these principals into your own working process; as such it's ultimately more robust than any framework could be.
- Since it isn't a framework, you're left to applying the principals while learning -- this obviously doesn't address those who are trying to speed up their project in the short-term-- though it does give them skills in the long term.
ERIC on JUNE 14
I like this concept, but the question I'm left with is: to namespace or not to namespace? The examples he gives look like they're not namespaced, but this is a topic for discussion. I've created a Conventions page for this.
Was a lead front-end developer at Facebook and advocates rethinking how CSS is approached at the enterprise level. She challenges CSS Optimization/Semantic Purists with pragmatic approaches for writing well structured code that is reusable for large teams.
- 2 main principles: 1. Separate structure and skin 2. Separate container and content
- Both a methodology and framework
Our Best Practices are Killing Us Presentation
ERIC on JUNE 14
+1 on this for sure! Don't like naming conventions like .oneOfThree but the concepts behind OO CSS are very critical as we look to build a large framework.
Boulton is first and formost a designer and advocate of web typography and grids. Therefor his approach and thinking is to support maximal flexibility and customization for designers to address the specific needs of content. He's a critic of the "box" approach to many grid frameworks.
Intro to Content Out vs Screen In
Smashing Article: Semantic Grids
Lead developer for html5 boilerplate, modernizer etc. he is also a lead on the Google Chrome project and is a big advocate of doing the least amount of alterations to what browser defaults are set to -- geared towards an eye for optimization and performance. Below are some of the thinking outlined in the tools they produce.
No print style sheet; use @media print method instead Irish Talks about Methods
The thought-leader for the responsive design or 'one web' approach that hopes to find elegant solutions to designing web in the current state of many platforms and many resolutions. The foundations are fluid grids, media queries and resizable images.
Mobile expert at Yahoo and a leader in the Usability and UX Patterns world he is critical of Responsive designs that do not consider Mobile as a completely different set of paradigms and constraints. Advocate of the Mobile First design paradigm of needing to think of a more comprehensive approach to mobile design than the "desktop smaller" approach.
CSS Preprocessors (LESS, SCSS, Compass, etc. ) have gotten a lot of gain from the front-end development world in the past 5 years. While there are many gains, they are not without significant drawbacks.
ERIC on JUNE 15
I'm highly in favor of using a preprocessor, and personally I lean towards LESS. This is because, from an implementation standpoint, it allows for cleaner coding and less monolithic styles. However, not too much good documentation has been produced on how to architect well put-together LESS file sets, so care will need to go into this.
Alice on 6/19
I'm personally leaning towards an approach that works with pre-processors but does not require it. Meaning we use the pre-processors ourselves to build the framework but build the output as modular and usable to both folks w and w/o preprocessors.
I think there's a deep need to address for folks in having well-structured modular libraries to use quickly (for prototyping and such) that is light weight and easy for them to deconstruct (for say the casual css writer), so I'm concerned if our final output is too cleanly mixed-down, those w/o the ability to use pre-processors will end up with something complied that they'll need the pre-processor in order to modify.
I feel we should build things so they are hot-swappable and droppable. For example, provide a grid but allow it to be dropped and allow developers to swap as changes happen. Have the LESS/SASS versions enhance the experience that allows folks to strip their html class declarations down, but don't precompile them down for people so those who don't use LESS/SASS can't easily reuse the modules by just adding the css class names.
Eric on 6/19
Agreed that preprocessors should not be required to use the framework, but that we should develop with it.
Preprocessors actually help modularity, in my opinion. They let us be very organized about the way we create our sheets (each entity could have its own sheet) and then we just have an importer that loads in all the preprocessed stuff. We could also break the code up into units so that, in addition to a complete sheet, we also provide modular versions of the sheets so that people can mix-and-match as they want.
One other thought to do mix-and-match styles, since we will certainly run a central, hosted instance of this (kind of like we do with MWF), we could also provide a script that can mix-and-match on-demand. In MWF, this is done in our JS Handler where there are some default pieces always loaded, but one can also define other things that get loaded when they want them. Geolocation, for instance, is loaded via js.php?standard_libs=geolocation. We could do something similar where your CSS/JS paths could actually define the modules you want in the GET string.
One thing I would point out, however, is that we don't want people to modify our files directly. If they do that, then they can't update when we update. Instead, what they should do is add their own additional stylesheets or, if they want to work with the precompiler, then they could add them in by adding in their own inclusions within the stylesheet. Again, if we provide a handler, another option is to allow them to be able to specify a path to their own stylesheet that should be included as well - the benefit to this approach over simple including a second stylesheet is that it minimizes HTTP requests, although it does this at the cost of screwing up caching, so we'd need to performance test if it's worth it. MWF does this in the JS Handler as well.