We’ve been experimenting a lot during the last years and we’ve also tried to have one year without defining any goals, just going with the flow and taking all the opportunities that arise.

We ended the year with one big learning: setting goals is important. Not because last year wasn’t a good one (in retrospect, we’ve had great achievements and a lot of happy moments), but because without goals we couldn’t have a clear way to measure our progress. We couldn’t know if what we’re doing was aligned with our vision, we’re just being reactive and got some luck on the way.

We also learned during that year that goals must be flexible. We enjoyed this time without goals because we’re more aware of the opportunities around us and that’s something we don’t want to lose. That’s why we not only define yearly goals and track them, but we also schedule some time to review and adapt them according to new opportunities.

Goal setting can follow many different processes and, during the past 5 years, we’ve been using and adapting a framework called OKRs (Objectives and Key Results) created by Andy Grove. If you’re interested in learning more about this framework I recommend you to start with ‘Measure What Matters’ by John Doerr, I’ll share just a part of the book that described the framework in a really simple way.

Objectives are the “Whats.” They:
- express goals and intents;
- are aggressive yet realistic;
- must be tangible, objective, and unambiguous;
- should be obvious to a rational observer whether an objective has been achieved;
- The successful achievement of an objective must provide clear value (…).

Key Results are the “Hows.” They:
- express measurable milestones which, if achieved, will advance objective(s) in a useful manner to their constituents;
- must describe outcomes, not activities(…);
- must include evidence of completion. This evidence must be available, credible, and easily discoverable. Examples of evidence include change lists, links to docs, notes, and published metrics reports.

John E. Doerr, in Measure What Matters

This blog post will give you an inside glance at our full process and some extra insights about how we define our goals at the beginning of each year.

Goal-Setting Process

Our 7-steps process to define and track goals.

Step 1: Define Yearly Goals

We start every year defining our yearly goals. So the first step is to schedule a team moment to discuss and define goals. You’ll find more info about this step below.

Step 2: Share Goals

It’s crucial to have goals shared with the team, they must be visible to everyone in the company and on a tool the team uses daily. At Subvisual, we use Basecamp for internal communication, so we have a to-do list with our OKRs where each Key Result is a task. That allows us to assign the team member responsible and to have a place to discuss the next steps and to share progress about each KRs.

Step 3: Define DRI & Contributors for each KR

Yep, we love acronyms, and here’s another one we use: DRI (Directly Responsible Individual), coined by Apple. This concept about fostering a culture of clear responsibilities and accountability within our team, and so it is part of the process.

The third step is to have a DRI for each Key Result; someone who’s going to be the KR’s ambassador, guide, and motivate the team to achieve what we’ve set for. At the same time, being DRI doesn’t mean the team member has to do all the tasks by himself/herself.

And since we’re a small team and each one of us needs to choose wisely the way we want to contribute, we also create a small task force for each KR.

Step 4: Definition of Next steps

For each Key Result we define the next steps, new habits, and whatever we’ll have to do to achieve them. This can happen async (on Basecamp) or with some work sessions. It depends on the DRI, the task force, and the Key Results’ needs.

Step 5: Track OKRs

Another learning from our experience: we need a system that ensure we remember our goals and they are guiding our priorities.

So every month, we have a team moment to share & discuss the progress of our goals so we’re able to make some adjustments if needed.

Step 6: Review & Adjust OKRs

This step is about keeping our yearly goals flexible. At the end of the first, second, and third quarter of the year we have a Subvisual Day (usually the last Friday of the quarter) where we do a retrospective, review our progress, and redefine our goals.

Step 7: return to step 2

Unless it’s the end of the year, and then we have to return to step 1.

How we define yearly goals

The first step of the process happens at the beginning of the year, where we have what we call Subvisual Days with the following agenda:

Day 1 — Prepare & Understand

We start by analyzing our last year and understand what went well, what didn’t go so well, what we’ve learned and what still puzzles us. After reviewing the previous year, we’ll be better prepared to define our future.

We need approximately 2.5 hours and we follow this session structure:

• [5 min] Expectations — we start with an explanation of how our work session will be and we also share some expectations for this and the next day sessions.
• [30 min] Self-reflection about last year — we usually share some retrospective exercises like Start/Stop/Continue analysis.
• [30 min] Add info on post-its, read and vote — usually 3–5 votes/person on the most important post-its we want to discuss.
• [15 min] Break — because we need a break after one hour of focus.
• [60 min] Team discussion — we take the most voted topics and start a discussion. We don’t expect to find solutions and define the next steps, we just want everyone sharing what’s on their minds.
• [5 min] Wrap up and a short description about what we’ll be doing during the next day.

Day 2 — Goals & Strategy

The second day is all about defining goals and strategies together and we need a full day for this. Our goals (objectives) tell us what is important to achieve and they should be ambitious, qualitative, and actionable. We start by defining 3 to 5 Objectives we want to achieve during the year.

The strategies (Key Results) tell us how we are going to achieve our goals. And under each Objective, we set 3 to 7 Key Results. They show us the most important things we need to do to achieve a goal and it’s important to keep in mind that they are not tasks.

This session starts at 10:00 and goes until 17:00. Here’s a regular agenda we follow:

Morning

• [30 min] Self-reflection about ‘What this year will be like?’
• [30 min] Add Goals on post-its, read, and vote on the 3 most important goals.
• [15 min] Break
• [90 min] Discussion & converge about objectives.

Afternoon

• [30 min] Self-reflection about key results for each goal.
• [30 min] Create smaller teams to share, discuss and define key results
• [15 min] Break
• [90 min] Share key results & team discussion

One small thing that had a huge impact on our work sessions is the time we set for self-reflection. It allows everyone to have time to think alone and take personal notes before starting a discussion. So don’t underestimate this time.

After these two days, Roberto and I gather together our notes, review every post-it, and define the first draft of our OKRs. This draft contains OKRs of the year and also our OKRs for the first quarter — the last ones are a prioritization of our yearly OKRs and more specifically about our next steps. That allows us to break our yearly goals throughout the quarters and ensure we can easily update our plans according to our context and opportunities.

And as soon as the draft is done, we send it to the team for some rounds of asynchronous feedback. After some iteration and back and forth feedback we have our goals defined. \o/

That’s all for today! 🙃 On my next blog post, I’ll share how we define next steps and track OKRs. Let me know on Twitter if you have any thoughts to share with me.

Originally published at https://subvisual.com.

How we set and track goals was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

You and your plastic brain are constantly being shaped by the world around you. Understand that everything you do, everything you encounter, and everything you experience is changing your brain.

Lara Boyd

To help you define what good habits you could be creating during this time at home, here’s a list of the ones I consider essential.

Habit 1 — Make your bed every morning

Making our bed in the morning might seem like something small and not really important. But “it will give you a small sense of pride and it will encourage you to do another task and another and another.”

Habit 2 — Drink plenty of water

You already know this but it’s important so here’s a friendly reminder. Keeping hydrated is crucial for your health and well-being.

And an extra tip: if you’re tired of buying water every time you go to the supermarket, buy a water filter and get it straight from the tap. 😊

Habit 3 — Get more sunlight

Our body creates vitamin D from direct sunlight on our skin. So, make sure you enjoy the sunny days and, during pauses, open a window to get fresh air and sunlight. This will improve your energy and sleep quality.

Habit 4 — Get quality sleep

Start by avoiding screens before bedtime, defining a routine, and being consistent with your bedtime. And if you want more tips about this, we recommend reading this book: Sleep Smarter by Shawn Stevenson.

Habit 5 — Don’t skip meals

Skipping meals may mean you’re missing out on essential nutrients and that will lead you to feel tired. So plan your meals, try new recipes, and keep a balanced diet (between healthy and goodness that makes your belly happy). 🤪

People who love to eat are always the best people.

Julia Child

Habit 6 — Stay connected

Keeping the distance from someone you love can be difficult. But we have technology nowadays that allows us to virtually stay in touch with friends and family. So don’t wait anymore and call someone!

Habit 7 — Keep mentally & physically healthy

Ensure you have a routine to take care of our mind and body. You can do it through mindfulness practices like meditation and yoga. The most important: keep consistency.

Habit 8 — Learn something new

Last but not least, strive to learn every day and if you’re not sure about why this habit is so important, check Ken Jennings’ TED talk.

Every day we should be striving to learn something new. We should have this unquenchable curiosity for the world around us.

Ken Jennings

If I caught your interest, check this blog post where James Clear shows that it’s not that hard to create new habits. The secret is to start with one small habit, increase it in small ways, and keep consistency.

I love the concept of neuroplasticity and the idea that we can, with some work, build new neural pathways in our brains and improve the way it works is really exciting to me.

If you’re interested in learning more about how you can create good habits and eliminate bad ones, I recommend you start with James Clear’s book: Atomic Habits. It’s, without a doubt, one of the best books I read this year and it truly made me think about my routine.

Originally published at https://subvisual.com.

8 Habits To Help You Through The Pandemic Times was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Subvisual, we never assume we know everything. We know there’s something new to learn every day. We also know that one of the best ways to learn is to put your hands on and share. That’s why we focus on training and continuous learning opportunities.

In 2020 we want to keep crafting our training opportunities.

If you want to pursue a career in technology and product, we have two programs in store for you! Our Apprentice and Summer Camp program.

In these programs, you’ll work in a creative environment with a mentor.

What’s a mentor?

A mentor is a member of our team. They will help you define goals, give your guidance, and answer all your questions.

And we have big news! This year our friends at Aurora, Finiam, and Onda will join our team of mentors. \o/

More about the programs

“They never offered me ready-made solutions, they showed me how to get there on my own, thinking about the problem from the ground up.” Francisco Baila, Designer

Both programs are a 10-week period of full-time work.

Apprenticeship program

As an apprentice, you’ll work on real projects with real impact, access to online courses, and create challenges according to your goals. Your mentor will be with you throughout the program.

Every 2 or 3 weeks, you’ll move to a different mentor. This rotation will be a unique development experience for you. It will allow you to work on different projects, meet our people, and apply what you will learn in different contexts.

Summer Camp program

The first 5 weeks are like our apprenticeship program. You’ll also have a mentor to guide you through your experience.

During the last 5 weeks, with the help of your mentors, all Summer Campers will form a team and build a product together to solve a problem of your choice. The purpose is not to create a product ready to be launched but to give you a taste of what it is like to work on a team and build a product from scratch.

👉One small note: as the name implies, our Summer Camp program will happen during the summer. If you’re studying, this may be the perfect opportunity for a season full of adventures, new learnings and fun.

Who is it for?

Students, recent graduates and experienced professionals are welcome to apply to our programs.

We have openings in:

• Programming
• Design
• Product Management
• Operations
• Marketing

And, regardless of your field of interest, we’re looking for independent and self-driven people. If you’re a curious mind, eager to experience new things and learn a little bit more every day, Subvisual is the place for you.

Teamwork and a user-centered approach are at our core. That’s why we value people who are, empathetic, humble, and good communicators.

How to apply

We’ve kept the application process simple so you can tell us about yourself the way you want.

Just send us an email at aloha@subvisual.academy with the answers to these 3 questions:

• What accomplishments/projects are you most proud of? Provide links if you can.
• How do you want to grow?
• Why do you think the apprenticeship/summer camp is right for you?

Don’t forget to tell us for which program you’re applying to. You can add a resume/portfolio if you want.

We’re flexible on the starting and ending dates.

Applications for an Apprenticeship are open throughout the year. For our Summer Camp, you should apply until the end of May.

Benefits

• Weekly allowance depending on where you live
• Free access to our office in Braga
• Free weekly physiotherapy session
• Free team lunch every Friday

At the end of the apprenticeship, we may offer you a position at Subvisual or at one of our partners.

💪 Join us! We’ll love to have you!

Hope to hear from you!

Apprenticeship and Summer Camp programs was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a company, we have evolved a lot in the last (almost) seven years. We started as a Ruby on Rails Development shop, working with companies from all over the world. Later we shifted to a Design and Development Consultancy firm and, even more recently, to a Venture Studio that helps founders create global companies. We are certainly proud of our past list of clients, from AT&T, DoctorLink and Uphold, to helping in the development of exciting startups like UTRUST or Coverflex.

Along the way, we organized events such as RubyConf Portugal, Creators School, MirrorConf, several meetups, and other initiatives that forced us to grow beyond our natural craft.

Turning Subvisual into a relevant company was accomplished by a fantastic group of 12 people. Helped by a vast group of friends that we have gathered from across the globe, to whom we will be forever grateful.

Internally, we fought hard to create a workplace in which everyone can feel welcome and part of the team. We make sure that we live by our values, and walk the talk. This can be something as simple as a weekly 30 minute catch up call, where we share what is going on in our personal lives, or something lengthier such as our retreat, where we spend 3 to 4 days together, rethinking the company, what we do and where we want to go.

In terms of hard skills, we’ve always been a full-stack oriented company. In our rapidly evolving environment, it was important for everyone to feel comfortable working on any level of the system, whether that was a design tweak on the UI or a performance issue in the back-end. We believe this horizontal knowledge to be essential, as it helps us understand the overall project much better, and allows us to communicate transparently with our clients.

Over time, however, we have grown not only as a company but as individuals. The nature of the projects changed a lot, and each of us started to tune their craft in a particular field.

Some of us focused on gaining expertise in building high-quality UIs for our products. Others have worked tirelessly on the infrastructure side to make those products more scalable and reliable. But our background as full-stack developers has allowed us to excel in different areas, without ever losing sight of the bigger picture.

We’re now looking for someone who can help us grow even more. Adding another human being to this equation as a full-time member of our company is something that really excites us.

About you

There isn’t a checklist of requirements that you need to tick to work at Subvisual. You don’t need proficiency with some technology, or a college degree. We expect that you love what you do, respect the job, and work sustainably.

For this role, the two things you need are knowledge in the field of UI development, and the will to learn more, the latter being way more important than the former. Having a Continuous Improvement mindset is crucial for us.

We set high expectations for ourselves, and we’ll set the same for you. As a front-end developer, you are expected to collaborate with everyone. You are expected to learn about animations, accessibility, and performance. And more importantly, you are expected to contribute and take the lead in these subjects. We want you to be passionate about the web and explore its boundaries.

You are expected to be autonomous. We rely on you to manage yourself and help manage others. You should be comfortable interacting with our global clients directly, so your English should be fluent. You will have to ask as opposed to wait to be asked. You should be open to and give clear feedback. We want you to take a stand and disagree, but also commit to the team’s decision when agreements need to be reached. We value strong opinions weakly held.

We want you to give back. It’s one of our core values. We want you to participate in meetups, organize events, write blog posts. Are you not used to that? No worries, a lot of us weren’t when we joined Subvisual. We are here to help you get comfortable with sharing. All you need to bring to the table is the will to do that.

You will have to be a mentor. Not only inside the team, but also the people that might join us looking to get into this industry.

Salary and Benefits

We don’t benchmark our pay. We pay honest salaries that we want to grow continuously. We aren’t yet in a position to pay everyone San Francisco salaries; we would love to. What we can offer is above the market salary, with quarterly reviews.

We offer a set of Benefits at Subvisual focused on your well being, mostly outside of work. We want you to live a sustainable life, where we respect your individual values, but nudge you to be healthier. That includes a Gym membership, health insurance, budget for books, opportunity to attend conferences, and other events, physiotherapy, and a lot of good moments to relax with the team as well as outside of the company.

We are remote-friendly, working towards becoming a Remote Team. We do still have two offices, one in Portugal and another one in Boston, both of which we will keep, but you are free to work from anywhere (within a reasonable timezone difference). We subsidize coworking spaces or home offices, to provide you the best possible environment to work, regardless of where you are. We will also invest in your continuing education, on the professional or hobbyist level.

We offer unlimited paid vacations, and you are free to take a longer journey once in a while, whitin reason. We do need to make sure that we continue a sustainable and profitable company after all.

How to apply

If you think this is you, send an application e-mail to hiring@subvisual.com with your name, your portfolio with visual examples of what you have done in the past, Github link and a cover letter explaining why you want to join us, as well as describing a recent technology you like and why you like it. Provided your application meets these criteria, we will be in touch.

Join us! We’ll love to have you!

Subvisual is hiring a Front End Developer was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

From the Postgres documentation we define an upsert as:

a (…) feature that allows (…) to atomically either insert a row, or on the basis of the row already existing, UPDATE that existing row instead, while safely giving little to no further thought to concurrency.

Obviously this logic can be implemented at the application level, although you then need to worry about the concurrency part. However, this sort of operation is exactly what we should enlist our database to help us with, as they are exceptionally good at it.

Upsert is a commonly used term to refer to adding an ON CONFLICT clause to an INSERT statement. As we’ll see there are different ways to define the target of the conflict but it always boils down to some constraint violation.

Ecto

Now that we know what Upserts are, let’s see them in action with Ecto. As an example, let’s say that we have bank accounts associated with a customer email, which should be unique, a balance and a boolean to lock accounts for security reasons.

With our database set up and schema in place we can go ahead and insert our first account!

Nothing fancy so far, however if we try to run the above statement again we’ll get an error from the uniqueness constraint on the email. If we know that the account is already there, we can use Repo.update/2. There is also Repo.insert_or_update/2 but it relies on us having an existing struct that might have been loaded from the db or not, thus it’s not an atomic operation.

Upserting

Let’s imagine a feature on a system used by a bank teller to create an account, they don’t know for sure if the customer is already in the system or not, but they just got handed $50 to deposit on that account.

We could do it in multiple steps in a non atomic way:

1. Check if the account exists
2. Create one with the balance if not
3. Update the existing one adding to the previous balance if yes

That’s too many steps though. Let’s do it all in a single step!

There’s a few things of note here, most importantly, the on_conflict option which takes different formats of input. In this case we are passing it an update like set of operation, namely the inc operation, which will do exactly what we wanted, by incrementing the previous value, instead of replacing.

Secondly, we use the conflict_target option, which goes in tandem with on_conflict. We simply state the conflict we care about will happen on the email field if at all, however, we can also specify a constraint by name if we want to be more specific.

Last but not least, we have the returning option. In this specific scenario it is not needed, as we are not using the return value of the call. In the case we did use it, we will usually want returning to be true as it will ensure we got the value that was persisted and not the struct we were trying to persist but couldn’t. More details on this can be found in the Ecto.Repo documentation.

Upserts with conditions

So far we’ve looked at how we can perform an upsert on every conflict, regardless of the row that conflicted, however, it’s a totally valid for us to want to do things conditionally.

Let’s take the previous example, of incrementing the balance, and add another constraint. We only actually perform the operation if the account is not locked, otherwise we return an error.

Remember how I said that on_conflict takes different types of inputs? Well, one of them (and the one that gives us more control) is a generic Ecto.Query struct, which we already know how to add conditions to, by using the where clause. All put together it might look something like this:

As you can see the on_conflict is now a standard Ecto.Query. We reuse the operation keyword list and pass it to update and we add the condition we wanted. There a few important things to have in mind as to how this query will be run, though.

1. The records from which it will select are the subset that triggered the conflict, not the entire dataset
2. The updates will be ran via an update_all, which do not update autogenerated fields, for example

Other than that, it should work pretty much as expected. In the example above, it will successfully increment the balance of the account if it is not locked, returning the updated value.

If the account is locked, however, it will return an error via an error tuple, the error will be stale_entry and will be applied to the changeset, on the field specified by stale_error_field. The reason this happens is because the insert didn’t actually insert anything, since the on_conflict query will return an empty set. Ecto treats these scenarios as a StaleEntryError and would generally raise, but in the upsert scenario we know that it might happen and stale_error_field is how we tell Ecto that we are expecting it, so there is no need to raise.

Conclusion

Upserts are a powerful tool to have in our database querying tool belt and can be useful in many situations. We do need to keep in mind that it is not without it’s drawbacks, though. For instance its use is not recommend while also working with associations, the insert call becomes more verbose or if we want to handle conflicts in more complex ways that involve system parts other than the database (by losing the atomicity), it might not be the thing for us.

We did not cover the on_conflict option extensively and I do recommend reading the documentation where you’ll also see :nothing and {:replace, ...}.

All in all it’s relatively simple to use and it’s a good way to handle scenarios such as the ones described above.

Upsert statements with Ecto was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have a confession to make. A while ago I hacked my own company.

Motivation

You might be wondering why someone would hack his own company. A company like Subvisual has a transparent communication and processes. So, if I want to know something, all I got to do is ask.

The answer to this question is Mr. Robot!
Yes, the TV show.

I’m a big fan of Mr. Robot.
For those of you who don’t know it, it’s a hacker TV series that’s very realistic. Instead of showing some random letters on a terminal they showed the viewers real techniques and exploits.

If you watched the series you certainly have noticed that our favourite hacker Elliot accomplishes some hacks by masquerading as a trustworthy entity and then simply ask for information directly to the victim.

This technique is called a phishing scam and despite being one of the most used exploits on the internet, it’s still one of the most effective.

I was skeptic that people would fall so easily on such a simple exploit so I became very curious on this. After some time I came up with a simple case study:

I wanted to create a phishing scam targeting my co-workers. The goal was to send a fake email to my whole team, containing a link to a malicious site, in order to see how many people would login on it, giving me their credentials.

If you put some thought on the matter your own team members are the perfect test subjects. You spend at least 8 hours per day with them, you know some of their habits, some of their tools and most importantly some of the sites they use and therefore some of the emails they receive. You also have the opportunity to watch first-hand how they will react when they see it.

Now you might be wondering if this is reasonable. After all getting someone’s private information might have a devastating effect on both the victim and the hacker, also worth mentioning that such action is… illegal. Considering that the victim will be sitting next to you this might not seem like a good idea after all. Also worth mentioning that my targets are experienced web developers so their defences are probably a step higher.

How can this be accomplished in such conditions? If you stick with me a little longer I’ll care to explain.

Preparation

My first plan was to attack the whole company at once keeping the whole thing secret and then, on a Friday Talk reveal what happened and how many people had fallen. After some days thinking on this and given the reasons above I changed the plan a bit.

The first thing I did was to ask permission and guidance to Roberto, our CEO. He received the idea surprisingly well and like me he was curious to know if our team would be able to recognise a simple phishing scam and if so, how could we improve the company security and awareness. We also shared the same concerns regarding personal information so it was decided that passwords or other relevant information would not be stored. The only thing that I would try to capture was the password length as proof that the given person had been victim of the attack.

With this set I began to prepare the hack.

After some time observing the team I noticed that most of our internal communication is done on Slack, Trello and GitHub. The emails that we received are mostly notifications from these apps so I started to analyse how easily I could create a clone of those and trick my coworkers to login to it.

My weapon of choice was Slack. The main reason for this was the fact that almost all of our important communication is generated on it. Theoretically if someone received an important email saying that he/she missed an important message this person should follow the link to catch up.

Here’s an example of a normal notification email from Slack:

The email itself shows the missing mention so you might think that this not an ideal situation. For an efficient phishing scam we usually need some content that requires an action, a hook that leads the victims to follow a malicious link.

For this to work I needed to change the content by inserting a partial message and a call to action button, but maintain the familiar layout and appearance.

Building the attack

This is the geeky part but there is not much to it on this field. All we need is a simple static web page and some place to save the emails and password lengths.

I chose to host the page on GitHub Pages and to use Parse as my attack storage for the sake of simplicity.

Then I started searching for a domain that resembled slack.com and indeed I found one available — slaack.co.

To clone the whole slack.com site I used an app called SiteSucker. This duplicates the site directory structure and files on your machine meaning that my cloned slack would look exactly like the original even on mobile.

With this set getting the emails and passwords lengths was very easy. I just removed the code from the login form and added some lines:

Finally, the fake email looked like this:

Attacking

This whole thing was online for more than 3 days, ready and waiting for the perfect opportunity. I chose to strike on a Thursday by the end of the day as people left the office. I sent the fake email. That way, as people arrived home, they would see an email notification from the team. Even better, they would see a notification from their CEO on a channel called “#secretProject” so the curiosity factor was involved.

Results

In the end 20% of our team fell on the attack (all of them are developers). While this number might seem acceptable, it is not. On such a sensible platform like Slack, where most of our company’s communication happens, a malicious attacker only needed one person to gain access to privileged information. Also worth noticing that if someone gained access to Slack this person could easily try to impersonate the victim in order to collect other information from the victim’s coworkers.

I presented this results on a Friday Talk and after some discussion I understood the rest of the people didn’t open the link only because they didn’t care about Slack email notifications. I also presented some context and countermeasures about phishing attacks that helped raising the awareness for this kind of vulnerability.

The most important lessons taking from this are:

• Nobody is safe from being victim of a phishing attack, even experienced developers can easily be victims.
• It’s hard to identify fake communication from the platforms we use every day. We don’t pay that much attention to it so it’s only natural that our defences are lower than normal.
• People now better understand the importance of security measures like two factor authentication.
• It was fun and a completely different approach to this security theme; by feeling the problem people understand better that they need to create defences against such attacks.

On the end what I have to tell you is to go ahead and do the same on your company. It’s easier to construct defences with a real understanding of the problem than just trying to fight something that was not experienced by anyone.

I will try to identify and correct more weaknesses in Subvisual and I hope you will do the same at your own work place.

Happy hacking.

Hacking your own company was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

If that is not the case, you’re in the clear, there’s nothing wrong with you, feel free to go, end this blog post now, be free, happy, enjoy the sunlight and the birds and the trees. Life is good.

.

.

.

.

.

.

.

.

.

.

.

.

… Are we, the sadists, all alone now? Cool. Ok, so you use vim a lot and you make builds fail. Chances are you would like to know when that happens without ever leaving vim. It’s alright. I got you, mate.

Here’s an asciicast of my nvim. Notice how the status bar includes, on the bottom right, the status of the CI. Notice how it updates. Damn, that’s neat. You want that.

First things first, either make an API wrapper, preferably in Rust or Go, something compiled and fancy, that allows you to check the GitHub checks API. Got it? Good. Now stop being a muppet and use hub instead.

Now that you have `hub`, you can make use of the `hub ci-status` command.

$ hub ci-status
success

Coolio.

Now let’s change our custom status bar.

First, we want to check if we’re in a git project:

let s:in_git = system(“git rev-parse — git-dir 2> /dev/null”)

if s:in_git == 0
 “ call hub
endif

So now we need to call `hub`. However just doing a `system` call to `hub` would be a blocking operation and we don’t want our vim to block every few moments for like 5 seconds. So let’s use `jobstart`.

Start by calling `:h jobstart` from your (n)vim. You can see that it runs an asynchronous job and it supports shell commands.

So let’s create a `CiStatus` function that looks like this:

function! CiStatus()
 let l:callbacks = {
 \ ‘on_stdout’: function(‘OnCiStatus’),
 \ }

call jobstart(‘hub ci-status’, l:callbacks)
endfunction

We define a map of callbacks for `stdout` and delegate that to a new function called `OnCiStatus`. This is a very simple function that gets the output from `hub` and converts it to whatever we want, storing it in a `g:ci_status` variable. We will later use this variable in our statusline.

function! OnCiStatus(job_id, data, event) dict
 if a:event == “stdout” && a:data[0] != ‘’
 let g:ci_status = ParseCiStatus(a:data[0])
 endif
endfunction

function! ParseCiStatus(out)
 let l:states = {
 \ ‘success’: “ci passed”,
 \ ‘failure’: “ci failed”,
 \ ‘neutral’: “ci yet to run”,
 \ ‘error’: “ci errored”,
 \ ‘cancelled’: “ci cancelled”,
 \ ‘action_required’: “ci requires action”,
 \ ‘pending’: “ci running”,
 \ ‘timed_out’: “ci timed out”,
 \ ‘no status’: “no ci”,
 \ }

return l:states[a:out] . “, “
endfunction

There are a couple of things missing though. This runs the `hub ci-status` job only once. We want to have it perform constant checks. If we do `:h timers`, we can see the new `time` API in neovim. Theres a `timer_start` that takes a period and a callback to run after that period.

We can then change our `OnCiStatus` function to call `timer_start` with that first `CiStatus` function again:

function! OnCiStatus(job_id, data, event) dict
 if a:event == “stdout” && a:data[0] != ‘’
 let g:ci_status = ParseCiStatus(a:data[0])
 call timer_start(30000, ‘CiStatus’) “ relevant new part
 endif
endfunction

Now `CiStatus` gets called by `timer_start` every 3 seconds. `timer_start`, however, passes the `timer_id` as an argument to the callback. So we will need to modify `CiStatus` to accept an argument (that we can safely ignore):

function! CiStatus(timer_id)
 let l:callbacks = {
 \ ‘on_stdout’: function(‘OnCiStatus’),
 \ }

call jobstart(‘hub ci-status’, l:callbacks)
endfunction

“ We also need to change the first CiStatus call to receive an int
“ Since we don’t care about it, let’s just use 0

let s:in_git = system(“git rev-parse — git-dir 2> /dev/null”)

if s:in_git == 0
 call CiStatus(0)
endif

All that’s missing now is to take the value of `g:ci_status` and put into the statusline. That’s pretty simple, using some code borrowed from Kade Killary.

set statusline=
set statusline+=\ \ \ “ Empty space
set statusline+=%< “ Where to truncate line
set statusline+=%f “ Path to the file in the buffer, as typed or relative to current directory
set statusline+=%{&modified?’\ +’:’’}
set statusline+=%{&readonly?’\ ’:’’}
set statusline+=%= “ Separation point between left and right aligned items
set statusline+=\ %{g:ci_status} “ Our custom CI status check
set statusline+=col:\ %c
set statusline+=\ \ \ “ Empty space

And that’s that. Find a lot more goodies in my dotfiles. Cheerios. Hugs n kisses and all that.

Jobs and Timers in neovim: How to watch your builds fail was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

First published on Subvisual’s blog.

Any project started at Subvisual has always been demanded the best development processes we know, to assure the highest quality. Among other things, this means we advocate that all our projects follow a Continuous Delivery process.

Recently we decided to start sharing this approach with the community outside our own ventures. And like any good teacher, we sought to learn more about the subject and ended up studying the Continuous Delivery book, by Jez Humble and David Farley. It so happened that, in that effort, we learned that we ourselves are not actually doing it, we only practice some of its ideas.

The Continuous Spectrum

Anyone who looks for it is bound to find several software development buzzwords with the “continuous” word on them, the most common being Continuous Integration, Continuous Delivery, and Continuous Deployment. These three are all different things but they are all linked.

Continuous Integration

Consider a regular software project using Git, where developers work on their changes in the isolation of their own branches, all originating from a main one (usually master).

Continuous Integration (CI) is a practice where developers are encouraged to integrate their changes in the main branch as often and as early as possible. Integration here does not simply refer to the act of merging the code, but performing whatever checks the team needs to feel confident the new changes did not break anything and are working as they’re expected.

Practicing Continuous Integration requires both a Version Control System (VCS) like Git or Mercurial, and a way to trigger an automated build pipeline when a new change is committed. This is usually done through a service like GitHub, Bitbucket, or GitLab, which provide a central repository for changes to be merged into, automatically triggering a CI service to build the project.

The build run by the CI service will depend on what the team considers required to feel confident nothing was broken by a change. This usually includes unit and integration tests, may also include code quality checking, and possibly a test deployment (to a staging environment).

For a team practicing CI, there is no task more important than keeping the build pipeline working. If the build fails, it is everyone’s top priority to fix it. And if the problem is not solved quickly (under 20 minutes, for instance), then the breaking change must be reverted and fixed in isolation.

Continuous Delivery

Continuous Delivery (CD) builds upon Continuous Integration. It boils down to being able to deliver any change whatsoever to production quickly and safely.

This means the project’s code must be ready to ship at all times. For instance, in a regular web project using Git, this implies that the master branch is always deployable, and keeping it that way is everyone’s main priority. It also means that the deployment process must be as easy and automated as possible, and that deployments should happen as early and often as possible.

Practicing CD implies the build pipeline includes a suite of acceptance tests (automated and/or manual) to assert the product does what it is expected, and possibly non-functional tests required to assert it is ready to be delivered (load testing, security checks, etc.). Once the build is finished and considered successful the team is confident it can be delivered to production.

One crucial distinction between Continuous Integration and Continuous Delivery is the approach to new functionality. CI requires only new changes not to break existing functionality, so unfinished features are accepted as long as the rest of the product works. But since CD requires the project to be deliverable, any unfinished features have to be hidden or disabled until they’re considered ready to be released.

Continuous Deployment

Continuous Deployment is just an extension on Continuous Delivery where the product is actually delivered on every change. It is a specially good fit for web products since the delivery process is completely under the team’s control, whereas a mobile application, for instance, would require users to download the updated version.

Typically a Continuous Deployment process will be fully automated, which increases the importance of having reliable acceptance tests. However, it is not required to be fully automated, and the build pipeline can also include a manual exploratory testing step. The difference being that once those tests are deemed successful, the tested version is deployed automatically.

At Subvisual we do not aim for Continuous Deployment because delivery is a business decision, not a technical decision. While Continuous Delivery fits all projects, the specific requirements for Continuous Deployment are not met by most projects, especially until a certain maturity is reached.

How to not practice Continuous Delivery

As I wrote above, we have been stating that we practice Continuous Delivery for a while, but the truth is that we actually don’t even fully practice Continuous Integration to start with.

Services like Travis CI, Semaphore CI, and Circle CI all use the CI acronym because the existence of a system able to test the main branch and make sure the latest changes do not break anything is essential for a project practicing Continuous Integration. However, just using a service like this to run an automated build pipeline is not enough.

For a team to practice Continuous Integration, there must be a culture of integrating changes to the main branch often (at least a couple of times a day according to some authors). This prevents pull-requests with hundreds of changed lines, or changing multiple different things, both of which make code reviews a lot harder and error prone. And while we do discourage long pull-requests, we never actually refuse them and force people to go back and break it into smaller changes.

The way we see it, there might be good reasons on why a developer is not integrating with the main branch frequently, like experimenting with a new approach or a refactor. But aside from very rare exceptions, large changes can always be broken into small and easy to comprehend chunks.

Even if we disregard that we are not actually practicing Continuous Integration, we still can’t consider we’re doing Continuous Delivery. One of the reasons is that, historically, the build pipelines in our projects do not run acceptance tests against live production-like environments. This is a side effect of the tools we normally use, which assume a clean and controlled testing environment for functional tests.

Normally, we also do not include any non-functional tests in our projects. These are tests designed to verify the application meets its non-functional requirements, like being able to handle a minimum number of users at the same time, or implementing some specific security rules, or responding to any request within a given time frame. Since ventures go on their own before that, there is rarely the need for tests like these when we’re working on the projects.

Take the case of Crediflux, for instance, which had a comprehensible suite of feature tests since its earliest stages. These were never run against a live environment. Therefore its releases required stakeholders to go through the most common flows by hand in a staging environment, and this would often uncover issues associated with the data already in the system. And as it also lacked any non-functional tests, it was only when the first big clients started using the system and the amount of data started building up that we noticed performance issues in some tasks.

In some cases there is another reason we can’t say we’re doing CD. Normally we use Heroku and automate the deployment process from the CI, but there have been cases where the project required another environment and the effort of automating deployments was considered to exceed the return-on-investment (ROI). Of course this flexibility of doing what is best for the project is required for any successful software team, but the truth is we should review this decision periodically and we don’t normally do so. And in every single case the project reached a point where the cost of doing it manually exceeded the tolerable, and the deed had to be done anyway.

–

In summary, if a project is often in a broken state (the build is failing), not ready to ship (feature X is not complete yet), or requiring human intervention to deploy successfully (we’re just waiting for Miguel to get here and deploy to production), then the team is not practicing Continuous Delivery. Without it, we’re losing valuable feedback both from tools we should be using, and from real users (because we’re not deploying as often as we could). And in order to fix this, we need to own it.

It’s not Continuous Delivery (yet) was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s say that you have an HTML file that looks like this:

When the cursor is on line two or four (the timepicker tag), you want to trigger a shortcut that opens the JavaScript file for the directive timepicker.

Ruby to the rescue

In this project, every directive is in the folder javascript/directives/, where the directive's name is also the file's name. If the name has more than one word, such as chart-timepicker, the file name would be snake case: chart_timepicker.

I’m assuming you don’t know enough VimScript to make this work (I don’t), but fear not, if you compiled Vim with Ruby support, this will be enough:

It’s a Vim function that you can trigger with C-] or call with :call AngularTemplateToDirective() (or map to a shortcut). Notice that it uses a module called VIM on line three. That module comes from Vim and it allows us to control it from the Ruby. If you want to learn more use :help ruby inside Vim.

This function fetches the current buffer and the current line. If the line matches an HTML tag (something like <timepicker> , </timepicker> or <timepicker something>), it takes the tag's name, turns it to snakecase, and opens the corresponding directive's file.

Cool right? Five years using Vim and there’s still so much to learn!

A little more advanced

With the function above, you can open directives from the HTML. How nice would it be to open CSS files from the HTML as well?

Taking the previous HTML example, when I’m in a line with class="timepicker" I want to open the BEM component named timepicker that, by convention, sits in stylesheets/components/timepicker.scss.

Building on the previous implementation, you first check if the current line contains class=", if not then look for the tag using the code from before. If it does match, you extract the component's name from the class, turn it into snake case and open the file:

I know that this code could be better, but I’m not concerned with that because it’s part of my Vim configuration, I’m always changing it, and it actually works!

I hope that you’ve found something new in this blog post. If you’re looking for more ideas for your Vim setup, check out this blog post from Miguel and subscribe to our blog. There are many Vim users at Subvisual and we always publish new content.

How to program Vim using Ruby was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.

First published on Subvisual’s blog. This blog post was born out of my necessity to find a structure in which I could rely on when designing any kind of web project.

0. Random

Before I started this research, my structure was very naive. When I came across a new project, my first move was to start drawing boxes and text blocks with randomly selected typefaces and margins. Not completely random of course, but with no serious thought behind it. If I needed a margin, I would start with 20px, and whenever I needed a bigger one I would double that value, so I ended up almost every time with margins like 20px, 40px, 80px and so on. The same with the typefaces chosen and their sizes. Selecting sizes always started at 16px or 18px adding 4px to get new ones. Once again the sizes would always end up being 16px, 20px, 24px and so on.

I started my journey on design through graphic design. In college, I spent a lot of time creating posters, books, and magazines. To do these kinds of pieces, I always went through very thorough processes of selecting fonts, sizes, margins, grids, etc. and I had excellent teachers that showed me how to do it. I liked doing graphic design, and I still do, but the web called me, and here I am, giving my first big steps after some big web projects. I also find myself asking why it is that I am not using processes like the ones I used before, on books and magazines, to do websites and products.

I am happy with the projects I’ve done so far, but I always get that feeling that something is missing. Some craftsmanship I would say. At Subvisual we care about our processes, and we are always searching for ways to improve them. The thing is that most of those processes are focused on User Experience, a subject that we care about. However, there is no good UX with a bad User Interface. I’m not saying that our UIs are bad. In fact, I think they are pretty cool but they lack craftsmanship. And you know, we strive for it. Curious and stubborn as I am, I went looking for solutions to this problem.

I started by googling and reading everything that could be interesting. I found some excellent articles, especially this one from Zac Halbert that ended up being an inspiration for this post and a formula that I used in my work ever since. I asked some friends that are working on graphic design how they are doing their stuff nowadays and found some books that helped me a lot in my quest.

Our Project — TurnGram

I’m going to take you through the process of bootstrapping a project using typography as base. We will start by the art direction and finish on the typography scale. Our project is TurnGram, a service that delivers your photos to your loved ones on a regular basis, hassle free. The design sprint has ended, our prototype is done and tested, and the first version will be born.

1. Art Direction

Let’s start with the Art Direction or goals, of the project. This is where we think about the mood of the project, the feel that we want users to have when looking to our website. Take the time to read the project’s copy carefully and to look at its images, if possible. We want to understand our project’s personality through its content. As you do it, write it down: cozy, familiar and nostalgic.

2. Hierarchy

Every structure needs hierarchy. You should take advantage of the time you are spending reading the content to set the rules of your project’s hierarchy. Set what is a text block, what is a heading, what is a secondary heading, and so on. Mark them, find examples for every type of content.

1. H1 — Some of our favorite TurnGrams;
2. H2 — Recipient Name & TurnGram Instructions;
3. H3 — Do you ship overseas and to P.O. boxes?;
4. Text block — I would like to send my mother (Maria Eastman) photos of my family on a monthly basis. She loves to display photos around her home and show her guests recent pictures of the grandkids. So please make sure to include the kids in your photo selections as much as possible.;
5. Buttons — Start Now;

3. Typefaces selection

Once there are no more examples to cover, it’s time to make the most important style decision. Let’s select the typefaces we are going to use.

From now on, every decision that we make has to take into account readability and legibility. As described on Wikipedia, readability is the ease with which a reader can understand a written text. Legibility is the ease with which a reader can recognize individual characters in the text. I will be addressing them through the post.

Picking a typeface early on a project’s life will change the way you will make decisions later. There is one book that helped me a lot on how to choose and combine typefaces. “The Elements of Typographic Style” by Robert Bringhurst is considered by many a typography bible.

The first two advices that Robert Bringhurst gives us are “Consider the medium for which the typeface was originally designed” and “When using digital adaptations of letterpress faces, choose fonts that are faithful to the spirit as well as the letter of the old designs.” Be sure that the typeface you want was designed to be displayed on a screen or, if it is an adaptation, check if the font weights and proportions are well adapted.

“Choose fonts that will survive, and if possible prosper, under the final printing conditions.” From this, we must bear in mind what sizes our typefaces will be rendered in, a question of legibility. Before choosing the typeface, go for its specimen and check what sizes it is best rendered in. Our example has some long text blocks so we should aim for a base font size of 20px. If you are designing a blog post, for instance, you will want to be using a base font size between 20px and 24px with a good x-height(the height of the lowercase). This is a rule that I regularly apply in my work, but like all rules, it can be broken when we feel it can work differently.

“Choose faces that suit the task as well as the subject.” This project’s personality is cozy, familiar and nostalgic, so we should pick a typeface that reflects this.

“Choose faces that can furnish whatever special effects you require.” If your content has a lot of numbers in the text, for example, you want to choose a typeface that contemplates text figures. The same goes to texts that need some emphasis where you could use italic, bold or even small caps.

“Start with a single typographic family.” A lot of the projects that we see using two families could be set in only one. We should take advantage of the resources that our typeface gives us before we appeal to a new typeface.

Summing up, these are the guidelines to keep in mind when choosing typefaces:

1. Be sure that it was designed to be displayed on a screen;
2. Look for a font that looks good on 20px;
3. A typeface that looks good on long texts, cosy, familiar and nostalgic;
4. Be aware if your content needs “special effects”;
5. Take advantage of the typeface resources.

Make sure you do a lot of tests with multiple examples from your content before you make a decision. The best way to know if your typeface is the right one is to read the content with it. I will choose Tisa Pro, a serif font with multiple weights. It looks good on 20px; it looks good on long texts; it’s cosy and familiar due to its humanistic stroke. I don’t think that Tisa Pro can be considered to be nostalgic but not every requirement as to be achieved with type. You can rely on images, illustration, color, etc. I’ve checked that Tisa looks good in every kind of content that we have so we are ready to go.

Almost ready. One thing that we can try here is the branding typeface. If you are doing a website for a project that already as branding work done, you should try to use its typeface or, at least, use one that looks good with it. However, in some cases, you will not like the branding typeface and that is ok. That is what happened to us here so we went in a different direction. Although it is good to stick with one typeface, we felt the need to use a different one because we were needing an extra layer of contrast.

We are going to use Effra.

3.1. Pairing Typefaces

When pairing two typefaces we want to have contrast between them with linking details at the same time. First, Tisa is a serif and Effra is a sans-serif which is a great contrast point. They have similar x-heights which prevent us from creating two different scales — we will address this later. Effra mixes a geometric basis with some humanistic details, great to both create contrast and linking details with Tisa.

4 . Sizes

In the previous stages, we have already talked about some points that will come in handy here. As I said earlier, to choose a typeface you have to know the job it will perform. We already saw that our website has some long text blocks and that 20px is a good size, this is our base font size.

With a base font size comes a base line-height. Line-height is your font size plus the leading you want to give it. Leading is the space between one text line and the next. If you want your user to read faster or if you need to save space you can reduce the leading, like in books or newspapers. You can do the opposite if you want your user to have a more relaxed and comfortable reading.

Now that we need more numbers we need a scale to be the logic behind them.

“By using culturally relevant, historically pleasing ratios to create modular scales and basing the measurements in our compositions on values from those scales, we can achieve a visual harmony not found in layouts that use arbitrary, conventional, or easily divisible numbers.”

Tim Brown

So we start with our base font size of 20px, and we want a comfortable reading. There is one tool that I find really useful and that will save our life at this point: modularscale.com by Tim Brown. This website lets you enter your base and a ratio and then it does all the math for you. In our example we want a relaxed pace reading so the ratio we will choose will be augmented fourth(1,414) 20 * 1,414 = 28.28. After rounding, our base line-height is 28px. Some other examples of modular scales:

1. Minor third(1,2) 20 * 1,2 = 24 - fast reading speed and great space saving;
2. Perfect fourth(1,333) 20 * 1,333 = 26,66 - good reading speed and good space saving;
3. Perfect fifth(1,5) 20 * 1,5 = 30 - super relaxed reading speed.
4. Golden section(1,618) 20 * 1,618 = 32,36 - super duper relaxed reading speed.

4.1. Modular Scales

These scales are everywhere. They can be seen in molecules, flowers, the human body and that is why they make things so much more harmonious than randomly selected numbers. If we see something made of the same numbers as we are it will look much more harmonious.

“Simple, right? And, at its core, the idea is pretty basic. But, oddly enough, it’s quite easy to both under-estimate its implications and over-estimate its complexity (at least once you start to dig into it a bit).”

Billy Whited

They started to first appear in musical intervals and have been used through history by architects, painters, musicians, furniture makers, and others. So, why shouldn’t we use them?

4.2. Typographic Scale

Modular scales will give us a visual harmony, a rhythm. Like in music, our websites and products need a flow that makes sense.

We have already chosen our scale so now you are going to apply it, creating our typographic scale. Remember when we set the hierarchy at phase 2? Let’s translate it now into numbers.

1. H1 — 28,28 * 1,414 = 39,988 ~ 40px
2. H2 — 20 * 1,414 = 28,28 ~ 28px
3. H3–20px (bold)
4. Text block — 20px (the base)
5. Captions — 20 / 1,414 = 14,144 ~ 14px (uppercase, bold)

I started at the base and followed what the modular scale gave me with my hierarchy in mind. For the buttons and labels, we are going to use 14px because we can use them in uppercase, so the legibility will not be damaged. When you are making these decisions make sure that you are testing them, don’t follow the scale blindly. It may happen that you find the scale not suitable for this task. In that case, go back and try another one. I will leave the line-height setting for later; you will see why.

5. Horizontal Grid

We can now start giving our first steps into our grid. The grid can be viewed from two perspectives, the horizontal and the vertical ones. Let’s start with the horizontal, the one that you may have seen more often. Grids are a fascinating subject; I recommend that you read “Grid Systems” a beautiful book by Josef Müller-Brockmann.

Grids allow us to solve visual organization problems. With these helpers it is easier to organize texts, images and other elements of our content. As Josef tells us in his book, the grid can only be conceived when we have an idea of the texts and images we are going to use. It is the content that is going to tell us our grid sizes.

We have already one size, the gutter (space between columns). The gutter should have the same size as our base line-height, 28px because this will be the most used margin.

Text lines should have an average of 10 words, so this will be our column width. We are going to pick some pieces of text from our content, set them at 20px/28px and adapt its width to the numbers of our scale.

452px is a good number for this. You don’t want to have text lines that are either too short or too long. Reading becomes more tiring, and it damages the readability.

We will start with 1440px of width because that is the maximum width to where we want to go with this project. In 1440px there could be three columns with 452px of width and between them two gutters with 28px of width. Our grid has a total width of 1412px.

Now, following Josef’s advice, the more columns we have, the more dynamic and creative we can be. So how about dividing our columns by 2? 452(one column) - 28(one gutter) = 424; 424 / 2 = 212 px(new column size). Our total grid size is still the same, but our number of columns is now 6 and our text block will occupy two columns and one gutter.

The number of columns should depend on the dynamism you want to give to your content as well.

5.1. Vertical Grid

The horizontal perspective is set. One more to go.

Baselines are where all our content will rest. With these lines it is much easier to align elements. So, our baselines are going to be half of the line-height, 14px and our scale will do the rest.

On good examples of print projects, all the texts are aligned with the baselines and that gives us an exquisite look that is hard to reach on the web. Go to modularscale.com again and pick as much margin sizes as your project needs and list them neatly; have them match your baselines. Your margins will need a role. This role will be to separate different sections, titles from text blocks, elements inside a section, and others.

1. 14,144 ~ 14 — Spacing inside an element;
2. 28,28 ~ 28 — Sub-section and text blocks or other elements;
3. 39,988 ~ 42 — Sub-sections;
4. 113,052 ~ 112 — Different sections.

Now that we have baselines we can go back to our typographic scale. We have lines every 14px, so we want our scale to match them.

6. Typographic Scale (with baselines)

We already knew our base line-height, 28px, the number right after our base font size, 20px. Text block — 20px — line-height — 28px — 2 baselines;

1. H1–40px; To know the line-height for font-size 40px you have to do a cross multiplication. So, if 20px -> 28px, 40px -> x, x = (40 * 28) / 20, x = 56. Placing this number in our baseline will give us 56 but but you may need to round it. H1 - 40px/56px - 4 baselines;
2. H2–28px/42px — 3 baselines;
3. H3–20px/28px — 2 baselines;
4. Captions — 14px; This case is not so simple. Font sizes that have the same size of baselines, or similar, need more space to breathe. So let’s add an extra baseline to this one. This will cause some imbalance when captions and text blocks are side by side. It’s something I’m still trying to sort out. Captions — 14px/28px — 2 baselines.

What has changed?

It’s easy to think that there is no real impact for users with this process but I’ll tell you what it has changed for me. Before this journey, I had no strong opinion on this subject. It was that feeling that something was missing that kept pushing me to start learning about it. Now, after some websites and products, I can say that my projects have harmony on them and that the content dictated the appearance of the project. It may be psychological, but I firmly believe it isn’t. People read my projects better because they have a well-thought scale. People will not get bored so easily because my websites are more dynamic now. We designers have to think about the people that use our products every day and they are worth every effort that we can put into them. I strongly believe that this is something that will have an enormous impact on a product’s lifetime.

What about the 8pt grid, responsiveness, communication with developers, and all that stuff?

As everything we do here at Subvisual, this process is not written in stone. We are always trying to improve ourselves and our way of doing things. This has proven to be a very worthy system to follow but with some flaws that easily solved with other methods like the 8pt grid, which we also use. Plus, the number of variables in this process is very hard to incorporate into our designer-developer communication. These and other reasons led us into creating our own structure combining what is best on all systems we have tried before. We are working and testing it and soon we will be able to share it with the world, it will be worth the wait, I promise.

References

Books

1. The Elements of Typographic Style — Robert Bringhurst
2. Grid Systems — Josef Müller-Brockmann

Posts

1. Harmonious Typography and Grids — Zac Halbert
2. More Meaningful Typography — Tim Brown
3. More Perfect Typography — Tim Brown
4. R(a|ela)tional Design — Billy Whited

Thank you!

Thank you for reading this, I hope you found it useful. If you have questions or something to share please drop me a line here or at twitter @fcBaila.

Typography as Base: From the Content Out was originally published in Subvisual on Medium, where people are continuing the conversation by highlighting and responding to this story.