Volunteer Work
Categories
0
Comment
It’s helpful to frame your inquiry in these descriptions:
- Web Designer – a designer focusing on visual design of websites
- UX/UI Designer – a designer focusing on user research and user interface of websites and apps
- Software – design software that helps in the design process
- Language – markup, stylesheet, scripting, programming language for front-end web development
Categories
I am currently making a curriculum for the basics of HTML and CSS.
Revisiting CSS Levels, I have written in the past about it:
The important thing to remember is to pattern it after the Levels of HTML wherein we must begin with Accessibility and Usability in mind.
And from there on, we build towards Visual Design.
Using this as basis, one could argue that Colors and Typography are “nice-to-haves”.
Can your design stand in black and white?
Can your design stand in a serif font?
Yes, it should.
Categories
After building the Content Structure (HTML) of your website, the next step in the process is building its Visuals (CSS).
To be able to ease the process of writing the style sheets, we must segment it into levels:
- Level 1: Default (browser level)
- Level 2: Normalize (boilerplate level)
- Level 3: Modify (visibility and sizes level)
- Level 4: Template (functionality level)
- Level 5: Theme (custom level)
Ideally, each level must be buildt on top of the previous one yet still independent. For example, leaving the style sheet at browser level must present usable information. The same principle applies as one builds the style sheet level per level.
Level 3: Modify
Related Activities
- hide accessible names
- hide components
- set default state of components thru class names
- active element padding
- spacings (margins between components and paddings around components)
- dimensions are set at 100% for Mobile-First
Level 4: Template
Related Activities
- set the functionality of utilities such as Search and Navigation
Level 4: Theme
Related Activities
- colors
- background colors/images
- icons
- visual elements (badges, logos, lines/borders, shadows, corner radius)
- borders
Categories
Previously, I’ve discussed a class naming convention in the form of:
<generic>__<identifier>–<specific>In this manner we are using a UI State class located up in the DOM tree – particularly in the body to manipulate different UI elements under it.
Take this as an example: in a site’s header, both the main navigation and search form are located.
<header>
<h2 class="accessible-name">Header Content</h2>
<nav class="main-navigation">…</nav>
<form class="search-form">…</form>
</header>How would you be able to affect the main navigation depending on the state of the search form if its class is only confined within its container? The answer might be “thru JavaScript” – undeniably, we would need JS in this topic but only for manipulating class names. The trick lies in putting the UI Type or UI State class in a place wherein both main navigation and search form are under it.
Why <body>?
What benefit do we get in having a global class located higher in the DOM tree? It lets us control different parts of the UI depending on the site’s or app’s UI Type or UI State.
It is important to reserve the highest element you can put a class on – which is html (for pertinent class names), thus, the second highest element we could attach a class attribute to is body.
Going back to our example, we would use the following UI State class to define the state of the search form:
<body class="ui-state__search-form–active">The body class, in words, translates to “The UI State of the Search Form is Active”.
Now, whenever the search form is active, you can already manipulate the main navigation based on that state.
Take a look at the demo on CodePen:
See the Pen Using <body> to Define UI States and Types by Brian Dys Sahagun (@briandys) on CodePen.
Categories
During the heyday of IE6, frontend design was in murky waters. The frontend designer would need to employ lots of hacks, patches, and workarounds just to achieve the look and feel of a grand mock-up. Remember:
- when we used
tablefor layout? - when we used a 1×1 transparent pixel as spacer image?
- when we exported images as masks to make rounded rectangles?
- when we used images as gradients?
These were just a minute part of the painful challenges frontend designers faced yet nothing stopped us from adapting to the crappy non-standard browsers of that time. We moulded the web into different appearances despite the difficulties. Remember the time:
- when pixel fonts were in?
- when DHTML was so fancy that sites had snowflakes falling on them and cursors were customized with trailing stars?
- of “Web 2.0” – the proliferation of badges, loading icons, fab aqua buttons?
- of letterpress typography?
- of minimalism?
- when full-screen images is the template of all websites?
Categories
- Information (HTML)
- Information Architecture
- Semantics
- Content Structure
- Interaction
- Presentation (CSS)
- Visual Design
- Interactivity (JS)
- Interactivity
- Animation