• Read more about Choosing the Best Language for the Project: Deciding between PHP and Ruby on Rails

PHP

The positives:

The potential downsides:

Ruby

The positives:

The potential downsides:

The ugly side of both:

Both either provide or use templating language/tools. This is a trap, don’t do it. Let server side handle server side, and front end frameworks handle the rest.

And the last word…

PHP may be a language that’s easier to use and pickup on the server side than Ruby, but historically it has a hard time competing with Ruby when it comes to its frameworks’ capabilities.

• Read more about In-App VS. Apple Pay

Let’s first start with the question, what IS In-App and Apple Pay purchases?

In-App purchases are extra content and subscriptions that you can buy in the apps on your iOS device or computer. However, not all apps offer in-app purchases. For example with some apps you can buy additional content such as a key that unlocks more features on a free app or a sword that gives you more power in a game.

Apple Pay purchases is a service that enables mobile payments and digital wallet apps that initiate secure payment transactions between contactless payment terminals and Apple iOS devices like the iPhone 6, iPhone 6 Plus and Apple Watch. In other words, you can make purchases at a store without your wallet, just with a simple touch of an app.

Now let’s really dig into the different items that you can purchase using either the In-App OR Apple Pay. Below are a few key differences between which items you can purchase by using either app-

In-App: sells virtual goods such as premium content for your app, and subscriptions for digital content.

Apple Pay: sells physical goods such as groceries, clothing, and appliances.

These days it’s ALL about cost so let’s cover the difference in cost of using the two products?

In-App: 70% of the purchase price of each item you sell within your app is paid to you on a monthly basis- NO credit card fees are applied

Apple Pay: FREE! (Credit card fees do apply)

Make sure to let us know which you find easier to use, In-App OR Apple Pay.

See: iPhone App Store Submission Checklist

• Read more about What Does it Take to Create Pakistan’s Next Disruptive Idea?

I, alongside other aspiring entrepreneurs and changemakers, competed in Pakathon to search for the answer to this daunting question of -- What is the next big idea in Pakistan? This was Pakathon’s third year hosting a competition which brought together all of the “do gooders” from major cities all over the world from DC to Lahore.

Pakathon Global culminated in Toronto. It gathered winners from each participating city to compete over the course of a weekend to put forward sustainable and effective ideas for Pakistan’s development challenges. The winner of the competition received $10,000 which would go towards funding their organization and access to over 80 mentors who aid the winning team in executing their ideas after the competition. This year’s DC winning team was Khayaal, which is a virtual community for young Pakistani women, sharing personal stories, thoughts, and insights on the topics that matter most to women.

Our team targeted our strengths to create and implement team roles. As Khayaal’s Data Analytics Lead, I focused on analysis and problem solving. Throughout the process, I found guidance from the building, measuring and learning methodology utilized in the Lean Startup. We only had 1 month to get our product out the door and tested, which meant we had to move fast under such a tight deadline. Even though we didn’t walk away with the grand prize,we were honored with second place and an unforgettable opportunity to pitch for change.

What’s our product all about? Check it out here.

Team Photo

By: Malena Lopez, Project Manager

• Read more about Our Journey to a New Brand

WHO WE ARE

Rebranding for any company is an evolution of itself. It can mean a new logo, name, symbol or design conformed into one new identity. Once known as two separate companies, Intridea and Mobomo officially became a single website & mobile application development company around 5 months ago. Instead of renaming the company we decided to keep the name Mobomo (we liked their name better)!

After the merger was finalized the next step was to develop a new identity for the our newly formed family, we had to figure out “who” we are as an agency. Luckily, we shared the same vision for “who” we wanted to be which made things fairly straightforward, but I know that this isn’t the case for all rebrands. WE are energetic, WE are agile, We ARE MOBOMO!

Any company whether they are rebranding or not should be eager for new changes and ideas that can further propel their brand which ultimately leads to success. A company that is stagnant or doesn't have the drive or push is destined to fail. A key to any rebranding process is taking all your learnings, both internally and externally, and applying them to your new identity. Along with applying your best practices learned through experiences it is important to listen, be open to all ideas and try new concepts, if not change will never occur thus a stagnant company is inevitable.  In this post I’d love to walk you through our REBRANDING process as well as our newest developments to our new brand that makes it what it is today.

OUR LOGO

A logo or icon represents a company's name, when someone sees that logo they immediately associate with a particular company or brand. As a newly formed identity, we decided a new logo was an immediate next step. After weeks of deliberation, our new company logo was decided on- the hummingbird. A hummingbird to us perfectly combines the energy we put into each project, with the gracefulness and agility that comes with a team who is able to rapidly shift to the needs of our clients.

The new Mobomo word mark, is a custom typeface that is strong and commands attention. Capable of standing out in an overly crowded space, and infinitely versatile, the Mobomo word mark stands as a strong foundation of who we are.

Finalizing THE BRAND

Selecting the right font can be detrimental to a new brand and as the first rule of thumb.. it should always compliment the new logo. For our primary font we chose FF Real for it’s simple and elegant, yet strong appearance that translates well across a variety of different mediums. Our secondary font choice is Source Sans Pro, which was selected because it compliments FF Real perfectly and is a great display font.

The color palette we decided on supports our core beliefs illuminating our agile and energetic spirit towards all of our work.

And no redesign is complete without iconography to help tell it’s story. We chose an icon library that works well both on and offline, it is one that’s simple in it’s level of detail but strong in it’s ability to be recognized.

Combine all of our efforts and you get our final product...!

By: Mike DelGuidice

• Read more about Takeaways from Microsoft IPC’s Bitcoin Breakfast

By: Malena Lopez - Project Manager

Yesterday, I had the opportunity to speak at Microsoft's Innovation and Policy Center on Bitcoin and the potential for banking the unbanked with some awesome people - Brian Forde from MIT's Media Lab, Brian Hoffman from OpenBazaar, and Jerry Brito from coincenter. While I consider myself a Bitcoin novice, I have quickly noticed the equalizer this digital currency can be in the financial landscape. It's truly a breath of fresh air as long as we keep the conversation inclusive and diverse.

That said, Bitcoin and the Blockchain are changing the way we think about currency, digital assets, and identity. During the panel, all speakers touched on thought-provoking and telling points.

1. Bitcoin is freedom for currency.
In a place where regulation is second nature, freedom brings us home to the realization that we can take control of our currency with its decentralization and permission-less trade.

2. Bitcoin can bank the unbanked -- using mobile.
McKinsey estimates that worldwide “2.5 billion of the world’s adults don’t use formal banks.” Let’s compare that with mobile penetration worldwide. At the end of 2014, there were a “total of 3.6 billion unique mobile subscribers.” That’s over 50% for mobile Bitcoin potential.

3. Bitcoin has a future.
Think about the Internet - It eliminated the middle man to access and put out information. You no longer had to be a doctor to learn about heart disease; you could do it yourself. Today, we depend on this decentralized model. Bitcoin finds its future in this same way.

• Read more about Forming A Design Team, Part II: Process

Here it is peeps, the second post in our journey to create a killer design team…PROCESS. EEEK,*GASP*...I know, firsthand, that process can be a “dirty” word, the bane of creation, and something most companies don’t effectively use. But in this post we’re not going to talk about traditional process, the one where X person get’s a job then hands over some requirements to another person and so on and so on. No...no, here we’re going to be talking about the design process, and yes the two go hand in hand and a lot of the same people are involved (or should be), but in this post I’m going to discuss the parts that make a design team stronger, more efficient, and produce better work.

So where do we start with our design process, especially in the ever changing landscape that is the web? Clark Wimberly from Invision has some great ideas in his post Reimagining The Web Design Process, most notably is that of an agile team. One that is able to easily adapt to changes, and make rapid adjustments as needed. No longer do we work (and live for that matter) in a world that has static or fixed content, so it’s only right that as a team we should be able to rapidly shift to match this.

He goes on to say that we need to stop using mobile first as a buzzword and actually start to approach our design process with smaller screens, using an “Atomic” approach, as Brad Frost would say (more on this in a minute). Clark couldn’t be more correct, especially since Google has recently (May 5th) said they are now getting more search queries on mobile than on desktop.

So, back to that Atomic Design thing...what is it? How does is play into our design process? It’s an amazingly simple, but complex, ideology on how to handle the design and layout of websites. Breaking it down to it’s most basic idea is that you start with a single “brick”, something like a font, or a few color options.Then take those pieces and make a small UI element, like a form or menu, you keep adding small “bricks”, bit by bit, until you’re left with an assembled page. From there it’s rinse, wash, repeat on the other sections of your site. So, how does this work into our process? Quite naturally, by taking our mobile first approach and combining it with this bit by bit assembly we can very quickly and early in the game start to target the areas of our layout that need adjustment, and make the necessary corrections before we’ve gone too far.

Methodology is just one aspect of the design process, there are actual steps, hence the process part, that should accompany that. What those steps are will vary from team to team, but loosely they should be: planning, research, design/development, iterate. What do these mean though?

• PLANNING: figuring out what the project timeline is, when it starts and ends, when milestones need to be met, etc. This is also the phase when we need to determine who will be involved throughout the project, making sure the right people are brought in at the right time.
• RESEARCH: Make sure that the problem we’re solving is the right one, ask questions WHY, HOW...dig deep to understand the project. Determine who our target is, establish restrictions and needs, to help eliminate questions that may arise later.
• DESIGN/DEVELOPMENT(and prototype): Start to layout the concept, get ideas down into something more solid. Simultaneously development can begin with prototypes to test ideas.
• ITERATE: Today a design is never truly finished, even after handoff things are bound to come up, so take feedback, comments, etc, and adjust your product to match the needs of it’s users.

A good process, much like a good team, needs to be agile in it’s execution. Not every project will have a need for every step nor will it all allow for every step, so it’s ultimately up to your team lead to make sure the right parts are followed at the right time. Remember that establishing or adjusting a current process can’t happen overnight, it’s a gradual shift, much like our Atomic Design theory, an effective design process should be built upon, bit by bit and allow for rapid adjustment.

Want to learn more? Check out Mobomo's post on Forming A Design Team, Part I: Structure

• Read more about Writing Code for Your Future Self

One of the greatest things about the web industry is the respect and generosity developers have for one another to share knowledge in this ever-changing atmosphere. Whether you're on a small or large team, solo coder or open-source hero, arguably the most important pieces of your code aren't code at all. Commenting and writing readable code can save yourself and teammates valuable time by quickly understanding what your code does without the countless hours you spent carefully crafting the most elegant code imaginable. Even if you're working alone, readable code can avoid those awkward situations of you having to figure out what genius (spoiler: you) wrote this awfully convoluted code. Other benefits include auto-generated documentation and speedier code reviews. So, next time you write the "one function to rule them all", take the time to rename it from doesSomething to addTaxToSubTotal and comment the hell out of it - your teammates and future self will thank you.

What is “Readable” Code?

JavaScript: it was the best of languages, it was the worst of languages. Because of JavaScript’s flexible nature, we can sometimes write code that looks very strange and hard to read. Here are a few guidelines you can follow to ensure you are writing readable code:

• Describe: Use descriptive variable and function names, even if they take longer to type. In six month from now, you’ll have a much better chance of understanding what a function does if it’s called getAllCustomerNames rather than getData.
• Simplify: Don’t over-engineer your logic to the point of unreadable complexity. Saving a few lines of code while giving up readability is not worth it in the long-run.
• Comment: Complex logic is sometimes unavoidable. When it’s not abundantly clear what your code does just by looking at it, comments can lend a helping hand in plain english. Don’t shy away from lots of comments either. Techniques like minification will strip out all comments for production code, so you don’t waste any precious bytes.

Refactoring for Readability

Let’s take a look at some code that could use help to make it more readable. Below we have a function that performs some actions on product information. I will refactor the function so that it performs the same actions, but is much easier to maintain and collaborate on.

function changeData (data) {
  if (data.price > 100) {
    data.label = "expensive";
  } else {
    data.label = "cheap";
  }

  return data;
}

This function is pretty simple, it takes a data object and sets the label property to “expensive” if its price property is greater than 100, otherwise sets it to “cheap”. Although this logic is simple, there are a number of changes that could be made to make this function much easier to read and maintain.

• Function name: “changeData” is not a very descriptive name. Since this function is changing product data in a very specific way, we can name the function as such. This will also help developers understand what the function does when it is called elsewhere in the application.
• Function parameters: “data” is obviously not descriptive at all. We should rename this to best reflect what piece of data is being brought into the function.
  Verbose logic: The if statement could be simplified into a ternary statement since there are only two possible outcomes for the label property.
• Commenting: We are missing comments for this function, which could provide some great context to the maintainer.

Let’s see what the refactored function would look like:

function setProductLabel (product) {
  /**
   * Set the Product label based on its price.
   *
   * @param {object} product The Product object to update
   * @param {int} product.price The total price of the Product
   * @param {string} product.label The current label of the Product
   * @return {object} product
   */
  product.label = (product.price > 100) ? "expensive" : "cheap";

  return product;
}

ProTip: Put the comment block inside the function so that if you print the function in a console log, the comments print with it.

Conclusion

Writing clean, readable and well-commented code is a skill that needs to be honed and valued. Many developers overlook this, but it’s really what can set you apart from others in your field. And remember any little bit helps, so use the guidelines above to gradually improve your code today!

Any questions, thoughts, ideas? Let us know!

• Read more about oAuth and usability

Case Studies

Type in the API key

We will get the API key for you

"oAuth Pure"
ExpenseBooks - oAuth

• Read more about How to Create Responsive Images

With so many devices and screen sizes, it can be difficult balancing act to make your site look great and perform well. Displaying low res images on a high res display can make a site look terrible. On the other hand, serving high res images to a low res device can needlessly create a sluggish experience. Responsive images can help.

NOTE: Responsive image techniques are best used for CONTENT images (<img src=””>). For background images, you can and should use CSS media queries to control how the image is displayed across various devices.

The goal of responsive images is to provide multiple image sources and any other details the browser may need when deciding on an image.

WARNING: Parts of the syntax are very weird and the results may seem weird due to the long list of factors at play. These factors include, but are not limited to:

• Viewport size

• Image size

• Image display size

• Screen Pixel Density

• Cache

• Browser

• *Bandwidth

• *Browser settings (User preferences)

*Not currently implemented

Introducing the source set attribute:

Srcset allows us to provide multiple image sources as well as the size of each image. It may seem odd to inform the browser of our image sizes, especially since the browser can easily determine this on its own. However, the reasoning behind this is to give the browser a leg up on the selection process; allowing the browser to intelligently decide, prior to downloading, which image to request.

Taking it one step further with the sizes attribute:

The sizes attribute allows us to inform the browser of the image size being displayed on a page. It includes syntax similar to CSS media queries for responsive layouts where the image display size is determined by the layout.

Again, it may seem odd to inform the browser of something it can easily calculate on its own or it may seem odd to include redundant code from CSS, but providing this info before the browser even has the CSS files will improve performance.

A bit more control with the picture element:

Lastly, the picture element provides more control, using media queries, to explicitly narrow down the browser’s selection of image choices. This is useful for implementing art direction or when image sizes change so dramatically they must be uniquely cropped for every layout.

Responsive images can be complex. However, when done properly, they can provide the very best experience for any situation.

For more details check out our codepen:

[codepen_embed height=300 theme_id=1 slug_hash='qdMQdb' user='Mobomo LLC' default_tab='result' animations='run']

• Read more about Forming A Design Team, Part I: Structure

For the last eight years, I’ve been doing the design thang, working with companies ranging from a two person team to a large open floor creative group. Adjusting to these various structures was second nature, and not something I ever gave much thought to until now.

With the recent merger of our two design teams - Intridea and Mobomo - a unique opportunity to assist in the restructure and building of our teams was brought to the table. I know this isn’t an isolated situation and the process is in no way easy!

Thus, for the greater of mankind, I will chronicle our journey; the highs, the lows, and everything in between! I’m shooting for a four part series, breaking each post into specific topics: structure, process, tools, and culture.

Structure

I went bananas scouring articles on best practices, must haves, and shit you never do! Everyone has their own “right way” to structure a team - some work, most don’t. And while the ways to structure a team are extensive, the golden ticket wasn’t really structure but specific traits that differentiated a successful from a “meh” team.

Now, like anything, if you don’t establish a solid platform - that jenga tower is gonna fall! So let’s ask a few questions:

1. What are the key roles?
2. What kind of team do you want? Singular focus, multi disciplined, elusive unicorn?
3. What is the goal of your team?

What Are the Key Roles?

As mentioned above, I’ve worked in an array of team structures, but what’s been most effective, not only in my career, but in my research, was that of a “traditional” formation. One involving directors at the top, followed by senior leaders who then oversee the junior level folks. Why does this approach work? There’s a funnel, a singular route of communication, and a cascading approach to mentorship.

Directors drive their team to ask the tough questions; pushing them to think in a different direction, from a different angle. You know never know if the problem you’re solving is the right one, until you ask “why”.

Senior designers are your battle hardened troops, the ones who can articulate and defend their position on a specific choice with facts and rationale. They’ll choose right, over right now, and will fight for what’s correct. They’ll also help mentor and develop junior designers, guiding them to make smart choices and back up their own decisions.

Junior designers will eventually take over the reigns for their senior counterparts, so it’s vital that they learn and develop the key attributes that will make them good mentors one day. Find people with the qualities your company values: hire slowly - fire quickly.

What Kind of Team Do You Want?

Now that we’ve figured out who to hire, we need to establish what kind of team we want. Should our team of designers also know code? Eat and breath exceptional design, and only design? Or should we focus on a strictly UI design team?

What I’ve seen, and what I’ve read, all seem to point to the same thing, diversity! Find folks who bring different strengths to the table and push one another to do amazing things. Though, I should say, there are some must have skills each designer needs:

• Be a problem solver, and enjoy it
• Possess a great sense of visual design
• Able to identify great work
• Able to take creative feedback without taking it personally (still a struggle for me)

Most of the other attributes can be taught or learned as they progress.

What is the Goal of Your Team?

Finally, what’s the goal of your team? What are you trying to achieve? For fear of sounding like a cop out, I’d like to revisit this question in the next post. This is a new venture for all of us, and seeing as we don’t really have a team yet, I can’t say what our goal is. I do know that it will involve creating amazing work, with amazing people, but as for concrete and tangible goals: TBD.

Got any insight on team restructures? Let us know!