FED-Marketing Collaboration Initiative – Big idea: Unify the web channel – (From the ODS/Moda Digital Strategy plan)
FED-Marketing Collaboration Initiative – Big idea: Unify the web channel – (From the ODS/Moda Digital Strategy plan)
0 0
moda_marketing_fed
Slide deck for Marketing FED meeting, based on reveal.jsOn Github Josh68 / moda_marketing_fed
FED-Marketing Collaboration Initiative
Creating process, standards, and guides for efficient and consistent design and development
Utilizing modern tools to implement industry-standard best practices in UX design and front-end development
The state of things
- Fragmented sites and fragmented codebases, even for sites with templates that look identical
- Designing and developing on the the fly, without appropriate planning for quality and long-term maintenance
- Almost no documented standards, including no complete web style guide
- Conflicting guidelines and patterns from project-to-project
- No regular practice of site/app optimization on the front-end, which can significantly degrade experience for end-users
- Lack of FED/Marketing collaboration and planning
Big idea: Unify the web channel
(From the ODS/Moda Digital Strategy plan)
Big idea
The current digital presence of ODS:
- A separate design for (fill in the blank)
- None of the sites are optimized for mobile platforms
Big idea
“[W]eb standards and style guidelines for web user interfaces will help development teams provide a consistent look & feel, common navigation, and ultimately customer experience…”
Goal: A Living Style Guide
Serves as
- A live, centrally updatable, web reference
- A standard codebase reference
- A platform for enabling smarter, faster, and more consistent design->development workflow
- A place to implement design and development practices that will make our sites better (faster, stronger, taller, whiter teeth, etc)
Core topics
- Responsive-adaptive design
- Typographic scale
- Form validation
- UI libraries, targeted tools, frameworks
- Theming vs browser chrome
- Branding vs native UI emulation
- Graded browser and device support matrix
- Marketing/FED Collaboration
Responsive - Adaptive
One site/application serves all devices
Elements of Responsive Design
Fluid
Design in proportions, not pixels
Elements continuously resize/reflow as viewport size changes
Elements of Responsive Design
Media queries and breakpoints
Page elements and layout can fundamentally change at specific viewport sizes, when device orientation changes, etc
Elements may reorder themselves, vertically and/or horizontally
Elements of Responsive Design
Responsive elements
Page elements like images may also be delivered in multiple sizes or versions for different breakpoint ranges
Elements of Responsive Design
CSS grid system
Defines columns, gutters, and rows, for clean and consistent layout
With a fluid, responsive grid, layout elements stretch/shrink horizontally and layout can also fundamentally change at specified breakpoints, determined by media queries.
Adaptive
Beyond media queries and breakpoints, other techniques are used to deliver unique content or UX tailored to specific devices or device capabilities
Mobile-first philosophy
Make design, UX, content , and development choices optimal for
- small viewports
- limited bandwidth
- touch-based input
- short attention span …
Mobile-first
Progressive enhancement
Mobile-first is an extension of "progressive enhancement" philosophy
- Mobile UX is baseline
-
"Scale up" for
- larger viewports
- higher bandwidth
- other types of input (mouse, etc.) …
Mobile-first
Allow mobile UX priority to guide design decisions, promoting leaner, cleaner sites for all users
Typographic scale
Similar to a layout grid, but specifically for creating consistent and visually pleasing typographic rhythm and flow.
- Take some of the guesswork out of typographic layout
- Approach based on established ratios and mathematical formulas
- Avoid layout breakage associated with “pixel pushing”
Form validation
All websites and applications should have predictable, meaningful, and unobtrusive form validation and client-side feedback
Currently, validation schemes are inconsistent, even within a single app, and have changed from project-to-project
Goal: Have a global approach, with documented standards, for simplicity and appropriateness of feedback
Toolset: UI libraries, targeted tools, all-in-one frameworks
The what and the why.
UI libraries we have used (jQuery UI and jQuery Mobile)
Strong points:
- Consistency of behavior across browsers and devices
- Style consistency (themes) "baked-in"
Issues:
- May take over too much, making customization difficult
- May conflict with other tools
- Not a single, responsive toolset (perpetuates mobile/desktop divide)
Targeted tools
We have also used and may continue to use many single-purpose tools, to deliver features such as
- stylized drop-downs and other form elements
- dynamic tables
- form validation and feedback
- date-pickers
- rich-text editors
- graphs/charts …
Targeted tools
Advantages:
- Use only what you need (potentially lighter weight)
- Won't take over an application
- May offer features not found in UI libraries
Disadvantages:
- Uniform theming can be more difficult
- May increase development time
All-In-One Frameworks
We are evaluating the use of newer, all-in-one frameworks that can provide, among other things:
- Responsive-adaptive design and tools with a grid
- Typographic scale
- Boilerplate markup and best practices, such as a "normalized" CSS baseline, for handling common browser inconsistencies
- Themable, minimalist UI library/toolset
- Sprites/SVG icon sets
- Features like form validation
Theming vs browser chrome
With some elements, particularly form inputs, we might debate the pros and cons of custom theming (i.e., branding) vs leaving styling to browsers (chrome)
Theming vs browser chrome
Some form elements (e.g., selects/drop-downs), must be fundamentally reconstructed by a library in order to be themed
Can add complexity for development and appropriate validation feedback
Theming vs browser chrome
Branding vs native UI emulation
- We are not writing native applications
- On the desktop, our sites and apps are Moda-branded
- On mobile, we have attempted to emulate the UI of a mobile OS (iOS, particularly)
Branding vs native UI emulation
These are two completely different tools that do the same thing
Not maintainable, or inherently in line with responsive design
Branding vs native UI emulation
If our goal is to develop responsive sites and applications, we propose that:
- It's too complex to maintain this dichotomy.
- We should design and develop to the brand, and not try to emulate an OS.
Graded browser/device support matrix
Establish and maintain a matrix of browser and device support, with categories such as (summarized from Yahoo's YUI library standards):
- A-grade: Fully tested browsers/devices that provide top-level UX ("advanced functionality and visual fidelity")
- C-grade: An identified set of browsers/devices that should provide minimally acceptable UX (aka, "core support"); a handful of these will be tested
- X-grade: Identified and expected to deliver good UX, but not tested; also all unknown/unidentified browsers/devices, and known new, but untested versions
- Unsupported (optional, and debatably a bad idea): Identified browsers/devices that may provide completely broken UX, or have no guarantee of "core support."
Graded browser/device support matrix
- Make decisions based on our own and industry analytics
- Should be reassessed every 6 months
Desktop browser trends
Browser version trends
Device trends
Platform trends
Trends for particular browsers
(Waiting for things to die)
Collaboration
Marketing and FED need to work together to develop standards and implement a living style guide
Both teams should be involved early in project planning, to evaluate the technical needs of design and the design requirements of development
Need to promote open and direct communication between Development and Marketing, while also acknowledging the need for BSAs to collaborate and remain informed