👋 Oi, mga repapips, Brian Dys here! I love music, photography, and creative stuff like UX design and art. This is a place where I collect my thoughts and works. Apart all these, I’m Jaycelle’s better half and Bryce’s dad. 🥰
About Snippet
Categories
0
Comment
If a team couldn’t be fed with two pizzas, it was too big.
Categories
In my experience as a designer (both for print and web), I’ve come to differentiate my approach to each medium in terms of spatial measurements.
For print, all I needed to measure are the margins, in inches–and it’s all “what looks good” from there. For web, everything must be pixel-calculated–the margin, padding, distance from each element, width, height, etc.
I wouldn’t be able to answer how many inches the image element is away from another element in a, say poster I’m designing–I could only say it’s just about the right distance from the other elements. But when you ask what is the height of the button on that app I’m designing– I could simply say it has a minimum height of 48 pixels (in 160 pixel density) and there’s 24px padding on both sides of its label and 18px padding on the top and bottom; it is right-aligned with a 32px right margin and it is 48px apart from elements before and after it.
The reason for this is that, unlike print, after designing a website or an app, a designer would go on developing that design (which is only just a concept) into something interactive thru a device’s display where one has to account for the very limited space and optimal positioning and size of the elements. Pretty much the same as after designing a poster, you go on printing it to be tangible.
Displays for the web are thru the devices’ display monitors while for print, it is the actual medium–like paper. Designing thru the display in mind means that one must come to terms with the unit of measurement–at least for the minimum size of an element–be it the minimum width and height of a touch surface or the minimum points of text on a poster. This means that, for digital, if your device could display a bazillion ppi, you must design for it using its css pixel or as I call it 48/160 – 48px as minimum width and height of interactive elements (based on Android) and at 160 ppi.
This way you would be able to account for the initial available space of the display using the optimum size of UI elements. Also, the end product would be at that actual size on the display–meaning, your 48px x 48px element is displayed as that (and not 1.5x or 2x zoomed in).
Categories
It’s easy to center-align a bunch of text:
[code lang=”html” title=”HTML”]
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
[/code]
[code lang=”css” title=”CSS”]
p {text-align:center;}
[/code]
But how do you center-align a list such as a ul or an ol with children set as inline (or side by side)?
Simply set the parent (ul) to text-align:center and the children (li) to display:inline-block
[code lang=”html” title=”HTML”]
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Contact</a></li>
</ul>
[/code]
[code lang=”css” title=”CSS”]
ul {
list-style:none;
margin:0;
padding:0;
text-align:center;
}
li {display:inline-block;}
[/code]
This is useful for footer links displayed in mobile browsers wherein you want texts to center-align.
Categories
Avoid making the user choose from too many options.
Do: set default options for users to choose from–ideally the most common and provide a way for them to choose what is not initially presented.
Avoid: presenting a wide array of options that the interface gets cluttered and the users confused on which to choose.
Choose the most common/natural path for the users.
Do: set default actions in the context of the task while still making other actions available.
Avoid: cramming available actions altogether; provide importance to actions which are more contextual than others.
—
Design principles are not rules to abide by but more of guidelines in designing products for users. They should be put in context and tweaked when necessary.
Categories
For the longest time, I’ve been using Adobe Dreamweaver and Notepad++ in developing the front-end of websites (and I remember trying out PageMill long ago and resorted to Notepad).
I’m looking into one of Adobe’s projects: Brackets.
Brackets is an open-source editor for web design and development built on top of web technologies such as HTML, CSS and JavaScript. The project was created and is maintained by Adobe, and is released under an MIT License.
Source: http://brackets.io/
It could be the middle ground between Dreamweaver and Notepad++–we’ll see.
Categories
…you’re translating all the features and functions of all software combined into styles and you’re making the browser a mashup of those software.
One day, Photoshop will have an “export to HTML and CSS” function wherein the lens flare filter I dearly love would be a bunch of vector shapes rendered by the browser.
And whenever I see the need to make the lens flare in my image more awesome, I could easily tweak it:
[code lang=”css” title=”CSS”]
img {
lens-flare-type:35mm-prime;
lens-flare-brightness:100%;
}
[/code]
By then, writing the stylesheet might become as easy as spelling my name in binary code due to its vast properties and values.
Then we’ll be back to GUIs again.