Category Archives: Design

The following video is the core content of the second part of a Desing Thinking workshop imparted by our friend Michael Gharabiklou, Founder/Managing Partner at Quor Studio. You can watch part one here.

On his visit to TangoSource’s México’s Headquarters, our friend Michael Gharabiklou, Founder/Managing Partner at Quor Studio, shared his knowledge about Design Thinking with us.

The following video is the core content of a 3-hour workshop and the first part of a 2-video series. It Includes the Design Thinking process and the importance of empathy in this methodology, among other topics.

As TangoSource’s role description says, web designers are architects of the web. They focus on the look and feel of the website; and so, they should be visual arts experts, who are skilled in color scheming, graphic design, UX and information flow. However, this is just a glance at the whole knowledge baggage that a web designer should own and dominate in order to create good and effective web solutions.

The web design process is not a linear path, but a convergence of multiple disciplines, techniques, and methodologies, which have to adapt to every project’s needs, whilst keeping up with the new technologies coming up every day. It involves and integrates several disciplines as Information Architecture, SEO, User Experience Design, User Interface Design, Graphic Design, Product Design, User Centered Design, and Front-End Development, to mention some of them.

However, many of the sources I’ve reached on the internet address web design just as development’s initial step, before starting to write the code. This development method approach is called Waterfall, in which every step leads to the next one, and every part of the team works separately and sequentially.

The Waterfall method starts with a project plan. Before any part of web development can begin, designers must have a clear vision of the final product in mind. The planning stage is upfront and quite extensive, but one of Waterfall’s benefits is that most of the times, web developers can accurately estimate the timetable and budget for a project.

This workflow approach was the most popular one until a couple of decades ago. And it certainly has its benefits, but one of its disadvantages is its lack of flexibility, as it doesn’t allow an open communication with the client and the rest of the team throughout the process. In many of the cases, if any part of the initial design changes, the team has to rethink the whole project.

Waterfall Model

During my recent experience working at TangoSource, I’ve had the opportunity to work with the Scrum Framework, one of the web development Agile Methodologies approaches which work through iterative, incremental cycles. It allows designers, developers, project managers and stakeholders to actively participate in the whole process, encouraging an open communication through it. Something to always keep in mind is that getting feedback from different perspectives is really valuable, as you gain team and customer insights for a faster testing and ideation.

In other words, in an Agile environment, the phases run parallel instead of following each other, as in Waterfall methodology. This way, design, development, and testing all occur at the same time, as the product is divided into smaller and independent parts, called Sprints. These Sprints can be individually released, according to the continuously evolving requirements and solutions, defined by the project’s needs. This also speeds up the feedback process and mistakes come to light, making bugs easier to identify and reducing time and money waste. Sounds idyllic, right?

Agile Model

These principles constitute the basis of the Lean Startup Mindset, known as the 3 step process: Build, Measure, Learn Feedback Loop. This infinite informational loop gives business the opportunity to create, launch, learn and iterate on new and old products, and it works as follows:

Build – Create a Minimum Viable Product (MVP) based on a set of assumptions.

Measure – Launch MVP and measure your hypothesis based on your assumptions.

Learn – Accept or reject your initial hypothesis and iterate on the MVP.

Build Measure Learn Loop

The essence of the Lean Startup Methodology consists of helping reduce time and risks associated with launching a new product to the market, by taking advantage of the efficient use of resources, and continuously testing said product for market risk. This is done by guaranteeing user’s interest before building the solution and testing for initial user engagement while continuing working on improving the solution to an identified problem.

As we have seen, Lean Startup Mindset and Agile Methodology share some principles and adapt them to their own techniques. This doesn’t mean that you have to choose one over another, but you can rather take from each one the tools that best fit you since they have their own way to add value to your own process.

In his article A Designer’s Introduction to “Agile” Methodology, Joel –who performs the creative work in a consultancy– gives us an insight into this, speaking from his own experience:

“As a designer, making the transition from freelancer to working within a big company with multiple teams on Agile projects, can be a big leap. In my experience, it is a useful framework to work within and its principles can even be used in your own personal projects.”

– Joel

If you’ve heard about the term ‘Agile Design’, it is simply the application of some of the agile development principles to the design process. One of this flexible framework advantages is that it can be easily adapted, according to different workflows, teams, and projects needs.

On the other hand, the incremental cycles approach can present some difficulties on the design end. One of the risks that a web designer might face while working with iterative processes, is potentially finding visual style inconsistencies between the early stages of the project and the final outcome. Especially, if there wasn’t a document defining the style guidelines from the beginning.

For this matter, defining a style guide is one of the best ways to ensure visual consistency. A style guide is an equivalent of creating a development documentation in which every project’s guideline is promptly defined. This guarantees us focusing every effort in the right direction and avoiding style incongruities during the whole process, or whenever future development or third-party production intervenes.

“The Agile approach of Continuous Integration is reflected in the use of style guides, because creating content first and then using it to build a flexible framework reflects the iterative and cyclical nature of Agile development. The iterative format comes from the ability to experiment, test and tweak the way the coded elements are used in a layout.”

– Luke Clum

If you want to dive a little more into this, Tom Greever has given us nine valuable Principles Of Design Implementation, which perfectly adapt to the iterative process design essence, and on which every design team can base to create their own style documentation.

These days, you can find several different tools out there to help you ensure not only visual consistency but also responsiveness and cross-browser functionalities. A great resource to use is the website styleguides.io, where you can find articles, books, and some other tools to help you as a starting point in your extensive quest.

Being aware of design principles is crucial for an effective digital communication, and therefore, a successful product. But it is also important to understand that visuals don’t construct the whole design, but just a part of it. There always has to be a solid communicative speech on which design decisions can rely.

As Matt Meazey said in his article The Web Design Process in 7 Simple Steps:

“Web design — and really, design in general — is all about finding the right balance between form and function. You need to use the right fonts, colors, and design motifs. But the way people navigate and experience your site is just as important.”

– Matt Meazey

Certainly, there’s more than one way to do things, but there is one main focus which has to remain as the center of our thinking process: creating real solutions for digital communication. Innovation is a plus. Always remember that as every project and team is different, you’re best off choosing the methods that work for you, and adapting them on the road.

Recently at Tangosource I was assigned to work on an internal project named Dev Jobs (see dev jobs on iOS and dev jobs on Android), where I had the chance to work next to great teammates and implement a microservice architecture with Ruby on Rails, nodeJS, JWT, Ionic, Docker, and several testing tools, including RSpec, Mocha, Frisby, and Protractor. In this first post, I’ll explain the basics of the microservice architecture.

What is a Microservice Architecture ?

Martin Fowler gives a great definition.

[1]“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

The Problem

Let’s have some context. We are building a server side application that must support different client side platforms such as:

• Desktop browsers
• Mobile browsers
• Native mobile applications

Also, we need to consume an external API service. In our case, Linkedin through Oauth2 for authentication. And the ability for users to chat between each other.

On an architectural matter we still had to decide between monolithic or microservice. So let’s dig a little more on this two.

Monolithic vs MicroServices

Monolithic

If we take this approach, we need to keep the following in mind:

• Build one application to rule them all.

• Use one language ( Ruby, PHP, JavaScript, etc. ) we could not take any extra advantages from other programming languages.
• The architecture needs to be flexible enough to support API through AJAX and render HTML.
• The development team needs to feel comfortable with the language we picked.
• Security. We will have a public API to serve mobiles/clients.
• Best tools for RTCP. So we can have a nice looking chat
• Testing. build testable code

I have seen great monolithic architectures that can support all of this. One of my favorites is RoR engines based or nodeJS services based applications.

MicroServices

In the other hand, if we go for MicroServices we must take in mind the following:

• Delegate responsibilities in small applications.

• We can use different languages per service. Which is the best choice per responsibility?
• How are we going to communicate each service ? Normally with tcp/ssl.
• How are we going to persist Data through services?
• Security: Protect the services.
• Testing: Test all microservices.

On a personal note, as a developer working on a microservice platform, I can focus only on the technical details wrapping a specific service. This does not mean I should not understand the whole set of services as a unit.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

— Melvyn Conway, 1967

Having this in mind, we had to start by making technical decisions, such as how to protect our API, how to manage RTCP, by nature HTTP is stateless which means is sessionless so for our case we had to maintain a session through tokens ( JWT ), at first we though maybe nodeJS for RTCP since nodeJS is strong for DIRT ( Data Intensive Real Time )  apps. But we had not only had to take care of the tech devs but also for dev resources, currently at TangoSource we have strong Ruby on Rails devs so we had to work all together and take advantage of the expertise of each team member, our best bet was to use RoR for business logic, and take advantage of nodeJS. So the combination of RoR and nodeJS makes the solution solid and strong.

Solution

For this particular project, we decided to go for the MicroService and have some fun! The first thing that we needed to figure out was defining the responsibilities per service. So we end up with 4 microservices.

• Ionic
  • More than a service, it’s the client side of the application. Ionic by itself is a front end SDK for hybrid mobile apps using AngularJS.
• IDP
  • Responsible for (a) providing identifiers for users looking to interact with a system, (b) asserting to such a system that such an identifier presented by a user is known to the provider (c) possibly providing other information about the user that is known to the provider.
  • This may be achieved via an authentication module, which verifies a security token, and that can be accepted as an alternative to repeatedly and explicitly authenticating a user within a security area.
• SP
  • In charge of persisting all user’s data, including interaction with the system. This service will contain all the business logic
• Chat
  • In charge of establishing real-time communication among users within the system.

We decided to protect the services with JWT

Architecture

Each square represents a service, and the lines are how they communicate between each other.

Ionic : This might be the most critical service of them all, but not the most important. We have 3 main components:

• Ionic server
  • An HTTP server in charge of sending all the assets ( HTML, CSS, JS ) to the next component.
• Ionic Cordova
  • A Mobile SDK, which provides the user’s interaction with the app, and consumes the rest of the microservices as resources. This component runs on top of 3 different type of devices.
    • Android
    • Ios
    • Browser
• Ionic App
  • Ionic admin panel, this panel allow us to configure GCM and APNS exposing a protected API.

IDP : This service is in charge of giving identity to a component/user. This service will expire a valid token with a component/user’s basic information on the JWT’s payload. Similar to memoization, this service will keep track of sessions using Redis on a basic TLS connection. Thanks to the RFC 7519 standard, this service can scale in other microservice based architectures and be reused.

SP : This is an API/Https service protected with JWT. This micro service is in charge of persisting all user’s interaction/information using MySQL with a standard TLS connection. It also manages the business logic.  

Chat : This microservice will provide real-time communication between users. This RTCP (real time control protocol) is being protected with JWT on the handshake process, and persists the communication activity on MongoDB, a NoSQL database.

Conclusion

Taking these kind of decisions is not simple. It requires a lot of experience in order to compare libraries/languages, you must at least know how they work, and it’s even better if you have used them. Remember that you will not build this by yourself, you are part of a team. It’s smart to sit with your team and discuss each individual’s strengths and weaknesses in order to make the best tech decisions.

DO NOT mix responsibilities of the micro services, instead identify your services. Add all the needed documentation to help the team such as /*Comments */,  READMEs, and Wikis.
A microservice architecture is not always the best approach, and could be painful if you are not careful.

We’ve been working with Heather Poon to provide open source art for a top down zombie shooter game. It is covered under the Creative Commons Attribution Share Alike 3.0 license