recentpopularlog in

robertogreco : sass   3

The “Other” Interface: Atomic Design With Sass – Smashing Magazine
"As front-end developers and designers, we’re constantly refining two interfaces simultaneously: one for visitors who load the website, the other for developers who have to tackle the code in the future, when adjustments or full-scale redesigns must be made. Yet we tend to assign the role of “user” to the first group, often forgetting that the code we write must work for developers in a similar way. We shouldn’t forget that developers are users, too.

If this is the case, then our convention for naming and organizing files is critical if we are to ensure active (and efficient) development in the future. But do we really design the partials, files and directories that make up this interface with a particular set of users in mind, with a set of clear goals, combined with precise, well-defined documentation? I don’t think we do.

Recently, I’ve been working on many different projects, each wildly different from each other. And the various problems I’ve faced while switching between the projects has made me wonder how we can drastically improve front-end accessibility.

We Need To Follow Atomic Design Principles In Our Style Sheets Link

Last month, in a post titled “Atomic Design,” Brad Frost argued that Web development could be improved. He suggested to developers that, instead of coding a form as a component that is reused throughout a website, they could style small modules — such as a placeholder, input field and text field — and then create each form by combining these chunks together. This process could be duplicated for navigational items, text with icons, floated objects and pretty much any other sort of front-end module that needs to be reused regularly.
“Atomic design gives us the ability to traverse from abstract to concrete. Because of this, we can create systems that promote consistency and scalability while simultaneously showing things in their final context. And by assembling rather than deconstructing, we’re crafting a system right out of the gate instead of cherry picking patterns after the fact.”

The theory is that by employing these distinct elements, a developer can speed up their workflow and write code more efficiently because they’re not forced to repeat themselves. This much appears to be common sense. Essentially, what Brad calls for is object-oriented design, which has been discussed in numerous articles and blog posts recently. That isn’t really what interested me about the idea, though — it was the naming convention that Brad chose.

He uses scientific terms to quickly describe what sections of a design should do; “atoms” are the discrete chunks (placeholders, labels, etc.), while “molecules” are combinations of these standard atoms. The simplicity here grabbed my attention, because ultimately what we’re discussing isn’t just a process for design, but also a distinction to be made in the user interface, as I mentioned earlier."
atomicdesign  robinrendle  2013  via:caseygollan  webdev  sass  css  frameworks  webdesign 
march 2016 by robertogreco
DrupalCon Portland 2013: DESIGN OPS: A UX WORKFLOW FOR 2013 - YouTube
"Hey, the dev team gets all these cool visual analytics, code metrics, version control, revision tagging, configuration management, continuous integration ... and the UX design team just passes around Photoshop files?

Taking clues from DevOps and Lean UX, "DesignOps" advocates more detailed and durable terminology about the cycle of user research, design and production. DesignOps seeks to first reduce the number of design artifacts, to eliminate the pain of prolonged design decisions. DesignOps assumes that the remaining design artifacts aren't actionable until they are reasonably archived and linked in a coherent way that serves the entire development team.

This talk will introduce the idea of DesignOps with the assumption that the audience has experience with a basic user research cycle — iterative development with any kind of user feedback.

DesignOps is a general approach, intended to help with a broad array of questions from usability testing issues, documentation archiving, production-time stress, and general confusion on your team:

What are the general strategies for managing the UX design process?
How do you incorporate feedback without huge cost?
What happened to that usability test result from last year?
How much space goes between form elements?
Why does the design cycle make me want to drink bleach?
WTF why does our website look like THIS?
* Features turnkey full-stack (Vagrant ) installation of ubuntu with drupal 7 install profile utilizing both php and ruby development tools, with all examples configured for live css compilation"
chrisblow  contradictions  just  simply  must  2013  drupal  drupalcon  designops  fear  ux  terminology  design  audience  experience  shame  usability  usabilitytesting  work  stress  archiving  confusion  relationships  cv  canon  collaboration  howwework  workflow  versioncontrol  versioning  failure  iteration  flickr  tracker  creativecommons  googledrive  tags  tagging  labels  labeling  navigation  urls  spreadsheets  links  permissions  googledocs  timelines  basecamp  cameras  sketching  universal  universality  teamwork  principles  bullshitdetection  users  clients  onlinetoolkit  offtheshelf  tools  readymadetools  readymade  crapdetection  maps  mapping  userexperience  research  designresearch  ethnography  meetup  consulting  consultants  templates  stencils  bootstrap  patterns  patternlibraries  buzzwords  css  sass  databases  compass  webdev  documentation  sharing  backups  maintenance  immediacy  process  decisionmaking  basics  words  filingsystems  systems  writing  facilitation  expression  operations  exoskeletons  clarification  creativity  bots  shellscripts  notes  notetaking  notebo 
may 2013 by robertogreco
Typeplate » A typographic starter kit encouraging great type on the Web
"Frameworks make decisions for you about how to organize, structure and design a site. Pattern libraries don’t separate styling and markup, making them tough to use in a truly modular fashion. We weren’t satisfied, so we made a thing that doesn’t do that.

Typeplate is a “typographic starter kit”. We don’t make aesthetic design choices, but define proper markup with extensible styling for common typographic patterns. A stripped-down Sass library concerned with the appropriate technical implementation of design patterns—not how they look."
css  design  fonts  typography  sass  webdev  via:litherland  webdesign 
march 2013 by robertogreco

Copy this bookmark:





to read