0
Comment
There are numerous types of user interfaces that we use in our designs – there are pages, screens, popovers, dialog boxes, alert boxes, sliders, tooltips, overlays, and the list goes on.
It is important for front-end designers to establish a system for naming such containers and reusing them all over our web projects via the class attribute of an HTML element (e.g., <div class="class-name">...</div>).
Say, for example, you want to define a container to appear as a dialog box. There are two important things to consider: first is the type of UI and the second is the state of that UI. The solution to this task is to hook up the class name of an HTML element with CSS. Then in CSS, the visual design for a particular UI type is already defined, as well as its different states (active or inactive).
The Naming Convention
Instead of mindlessly coming up with names, we must establish a naming convention (very similar to BEM) to help and guide us with repeatedly naming class names depending on the need.
In general, we would start from generic to specific in this syntax:
[code]<generic>__<identifier>–<specific>[/code]
The generic name says something about the whole naming convention – whether it’s a type of UI or a state of an element. The identifier is the element that narrows down towards the specific (in some cases if it answers to the generic name, it is the specific name). The specific name answers to the generic name similar to attribute="value" syntax (i.e., generic="specific").
Consider wanting to classify an element under a dialog box type of UI:
[html]
<div class="ui-type–dialog-box">
…
</div>
[/html]
Or defining a state of the dialog box:
[html]
<div class="ui-type–dialog-box ui-state__dialog-box–active">
…
</div>
[/html]
In our example, the generic names are ui-type and ui-state and the specific names are dialog-box and active, respectively. In the case of the generic name ui-type, dialog-box acts as the specific. And lastly, the separator between a generic name and an identifier is a double-underscore __ and the separator between a generic name or an identifier and a specific name is a double-dash --. The separators make the relationship between the names easier to understand and the syntax, easier to read for different front-end designers sharing front-end documents.
Further Reading
Hey there, welcome to Design DriveThru Blog.
This serves as our idea scratch paper – like the tissue you get a hold of in a restaurant during a light bulb moment.
The main purpose of this is to document work in progress about Front-end Design stuff. The secondary purpose is to share the thoughts with the design and development community.
I hope this gets productive and helpful.
~ Dys
The Phone
The year was 1998. The place, Taft Ave., Manila. Clad in plaid shirt and my khaki slacks were accentuated by a brick in the left side pocket.
It was a Nokia pre-5110 model (similar to the one pictured). I took it out of my pocket, extruded the antenna to gather some signal and called my mom.
I just hit a deadspot with Angular.js tutorial at Code School.
I wished that aside from the “Use a Hint” action, there’s also an available “Show the Answer” (for frustrated learners like me).
Time to skip this part!
Two of the ways in which you can show an illusion of a button being pressed are: darkening the background-color and nudging its vertical position.
[codepen_embed height=”360″ theme_id=”1820″ slug_hash=”nmEcq” default_tab=”result”]See the Pen Press Time by Brian Dys Sahagun (@BrianSahagun) on CodePen.[/codepen_embed]
It is important to provide for a hint when a user activates an element in your user interface (in this example, a button). The feedback assures the user that the element “responds” to his action.
The advantage of using transform: translateY is that it does not affect the elements around it (unlike using margin or padding).
Commenting is disabled.
I remember a talk I had with Jayce during a cab ride to MRT, I was telling her about a difficulty I am having with my team about managing projects and deliverables and mostly about their productivity which is greatly dependent on my plans to develop and further each of our careers.
I realized in the process that I have my own inadequacies especially my own productivity, the way I am not focused on their individual projects because most of the time I leave them to plan their own day and I plan my own. Which resulted in a vague sense of accomplishment. What did we finish this week? Can it be improved? Should be do something better than having lots of free time?
So I resolved in resolving my management style first before taking it on other people in my team.
This week, I am being hands-on and aware that I am not micromanaging anyone. Because nobody likes even the worst or best micro-manager in the world.