A friend of mine asked me what my preference was when it came to relative font sizing for the web: em or percent?
Briefly, ems are relative to the font set in the CSS, and therefore, scaleable. If you don’t have anything set, then your 1em will roughly equal 12pt or 16px. Percentages are like ems, except that 100% is equal to the current font size.
At any rate, I prefer ems, ‘cause:
1. That’s what my mentor for front-end told me to do.
2. To me, it feels closer in theory to points and picas, which are the units of measurement I learned during my old school days of print design.
3. It’s easier for me for visualize an em than a percent (e.g. 1.5em vs. 150%).
I told him to go with what he felt most comfortable with, and try to stick to that standard throughout his styles.
HOWEVER… most designers prefer to use ems ;)
For more information, including a more detailed explanation on the difference between percentages and ems (and points and pixels), check out CSS Font-Size: em vs. px vs. pt vs. percent
Photo: A Roman Alphabet and How to Use It. Public domain.
posted by kittysingsuwan on May 10th, 2013. typography, web design. no comments »
In lieu of quizzes, tests and grades, The Starter League asks its students to participate in Starter Night every quarter. It’s not mandatory, but it is a great way to gain experience with a project team, and also a good way to put everything you learned to great use. Plus, there’s nothing better than being able to say, “I began with zero knowledge at week one, and was able to build something with a team by week eleven. Allow me to demonstrate.”
Most of us jumped at the opportunity.
My team, consisting of Mike Dorrance, Mike Land and myself, formed around Mike D’s idea for Adventurr.Us – an app that helps families discover outdoor activities by age. A parent initiates the discovery process, and family members keep the conversation going through searches, bookmarking, reviews and badges. Parents gain a better understanding of what their kids like. Kids have a say in what they do. It’s a win-win for the entire family.
Bear in mind, most teams (like mine) formed after the first hackathon, around week seven, which meant we only had four weeks to put it together. Mike D., Mike L. and I not only designed and built the entire MVP (minimum viable product) in that time, but we were live by Starter Night. Here’s how we did it:
1. We embraced agile development
We planned, but not for too long. We white boarded, but not for too long. We wireframed, but not for too long. We wrote user stories, but not for too long. We made up our minds quickly. And quickly changed our minds. We let go of anything that didn’t work. We set aside anything that held us back. We relied on a constant feedback loop – from our mentors, testers and peers – to keep us on track. We pivoted on a dime. We pivoted on many dimes.
We weren’t afraid to ditch what we had and start all over, because we knew that was the most efficient path to take. Which is exactly what we did halfway through the project. So in reality, our MVP was only two weeks old by the time we unveiled it to the world.
2. We played to our strengths
We were all in the same web dev class, and we all had a hand in the web dev portion of this project. But it was also clear, very early on, that each of us had our strengths, and that in order to succeed, we had to play to those strengths. Mike D. was a natural project manager and had a penchant for user experience, Mike L. loved Ruby and took ownership of the heavy lifting on the back-end, while I embraced the visual design and the front-end development.
3. We over-communicated
All the time. Via email, Github, ScrumDo, and in-person. We sat near each other in class. We sat together outside of class. We were constantly talking to one another about our model associations, back-end functionality, code, visual design, user experience, bug fixes and milestones. We made sure that our commit messages were clear and concise, and that our scrum board was up-to-date. No one really took a step forward without the other two knowing about it. And if that wasn’t communicated in-person, then it was surely communicated via email.
4. We weren’t afraid to ask for help
And we gracefully accepted the help we were given. Our mentors extraordinaire (Rafi, James and Brian) gave us valuable input on our data models, code and user experience. Our team advisor Kelsey helped us rework our data models. Our classmates Gareth and Ben, along with our TA Arjun, got us through some really tough coding moments. Gareth also coached us through our presentation, while Mike D’s wife, Christine, provided visual design backup. We couldn’t have made it to Starter Night without their love, help and support, and we owe them a world of thanks.
5. We believed in the project, and each other
It was the thing that kept us up at 1am. It was the thing that motivated us to code together all day, and continue coding when we got home. It was the thing that got us to code all weekend long, for four weekends in a row. It got us through the lows, the hiccups and the highs. And it is the thing that will keep us going.
And now, need your help. We’re looking for feedback on our MVP, so we can further improve and refine the product. If you’re a family that loves the outdoors, please join the movement. Sign up to become an Adventurr.Us beta tester today.
posted by kittysingsuwan on April 5th, 2013. design, the starter league, ux, web dev. no comments »
Did you know that your actual password is never stored anywhere? Nope. Never. ‘Cause if you, as a developer, decide to store actual passwords, and an account gets hacked, you put yourself at risk for all sorts of legal implications.
So what most developers do is store an encrypted version of your password. And whenever you sign in, whatever you type in for a password gets encrypted, then that is compared to the stored encryption. It’s encryption against encryption. And developers usually employ a third party add-on to run the encryption, making it so they can’t decrypt. They also set it so that this information is filtered out on their server logs.
There’s a little more to it, but that’s the gist of it.
So if you have a site that emails your actual password to you when you click Forgot Password, beware! It means your actual password is stored somewhere in their database, and vulnerable to hacks.
Lastly, the most commonly used password on accounts that have been hacked is… you’ll never guess… ‘password’. The second most commonly used password that’s used on accounts that have been hacked is ‘password123′.
For real.
Until next time,
K
Photo credit: Password Required by ItzaFineDay (used with permission under a Creative Commons License).
posted by kittysingsuwan on April 1st, 2013. newsletter, the starter league, web dev. no comments »
