• Read more about Tips For Your Mobile App Design

Mobile apps have become such an ubiquitous item that it seems everyone imaginable has one, literally everyone… even Barilla pasta has an ‘iPasta” mobile app. The question is what sets mobile apps apart from the OK from the GOOD from the GREAT?

Designing a great mobile app is no simple task and it’s more than just what the app “looks like”. We have compiled a small list of helpful tips to think about while you make your next mobile app. 

Execute one thing, really well

Ok so obviously.. Right? Everyone wants and needs to execute something in order to be successful. Being able to have a functionality that you can execute on really well is the foundation for all great apps. Think about Netflix, Uber or Dropbox-  they do ONE thing really, really well. They each became extremely successful by not over complicating their purpose, Netflix: watch a movie/TV show, Uber: find a ride, and Dropbox: access your files from anywhere. Each started with a single purpose and each grew to become much more than that.

To be truly successful you need to focus your energy on making sure your product does one thing perfect. Whether that’s showing people where the cleanest water fountains are in the city, or rating their favorite libation. Our suggestion would be to start small and then add features to your core application once you have established what you are and what you want to be.

Solve a user problem

If your application doesn’t solve a need that people currently have it will never be successful. The market is flooded with apps that do little to nothing at all for the people who download them. If a user doesn’t see benefit, well more times than not the user will delete the app. Users are looking for something out of your app- you need to be able to give them something in return.

People have little to no time to spare on your product, so creating something that can save them time, or give them some time back will make a huge impact. Apps like Operator, which offer on-demand “concierge” type services for buying products are on the front line of a new wave of app design. By allowing people to shop with a simple text request you can save someone hours of site browsing, allowing them to spend their time doing things that matter most to them.

Consistency

Making sure that your app has the same feel throughout does several things. It ensures that a button designed on one screen looks and acts the same on every other screen it appears on. It adds a level of polish to your finished product that makes it more professional, and it establishes an interface pattern that allows users to recognize similar elements on different screens. Without consistency in your application users will get frustrated and annoyed.

User experience

At Mobomo, we take user experience seriously. We make sure that all of our designs are user centric. You need to account for things like empty states, error pages, users who are less savvy, physical and technical limitations,etc.

The best way to make sure your application meets these requirements is to ensure that your discovery and IA phases dive deep into what your users are expecting to get out of your product. Make sure that their needs are being met, and that your business needs are aligned with their expectations. Doing things like user testing and user interviews will help you to get to a place where you can truly understand what it is that your users want.

Lastly, make sure you’re listening to the people using your product. Take their feedback seriously, listen to what they’re saying and refactor your application to meet their needs.

Pleasing visual design

While visual design is far from the only part of your application, it still ranks as one the most important. An aesthetically pleasing product is like having a well manicured lawn in front of your house, it’s the first thing people see and can either drive them to explore further, or turn them away entirely. Recently the Nielsen Norman Group released an article stating that users are actually more tolerant of minor usability issues if the application or product is visually appealing.

Fast and reliable

Last on the list is the optimization of your application. Make sure that your code is written as concisely as possible, fixing any bugs that arise as soon as possible, and making sure any bitmap assets are as compressed as possible will help to keep your product running fast and smooth.

Now it will take a little more than just this list to create a well designed mobile app, but this is a pretty solid foundation, and one we follow here at Mobomo on our projects. We’d love to hear from you about your thoughts on the subject too, what steps you take and any tips you might have.

• Read more about Brian Lacey Named As Industry Chair of Advanced Technology

CEO of Mobomo Named as Industry Chair of Advanced Technology Academic Research Center

Washington, D.C. --- Mobomo, LLC, headquartered in Washington, D.C., is a premier mobile-first web and mobile application design and development company that has extensive experience in working with federal agencies and commercial enterprises. Brian Lacey, CEO of Mobomo was recently named as the Industry Chair for the Advanced Technology Academic Research Center (ATARC) Mobile Customer Experience Working Group.

The ATARC Mobile Working Group is a technical working group of government, academia and private industry thought leaders collaborating on topics of interest to the Federal mobility community. The group’s goal is to provide the Federal Government with recommendations for methods to increase efficiency and reduce cost using cutting-edge mobile solutions.

“I am thrilled to be named an industry chair for ATARC. There is always work to be done to customer experience technologies and techniques to improve the public-facing mobile applications,” says Brian Lacey, CEO at Mobomo, LLC.

Mobomo specializes in working with government agencies helping enable technologies and improve the way they serve and engage with users. Not only does this benefit the user but agencies are seeing benefit through cost savings.

• Read more about How Automated Testing Is Saving QA Jobs

A couple of days ago I was raving to a QA tester about one of our automated browser testing initiatives at Mobomo and how it could greatly benefit the quality assurance field as a whole as well as free up time for our manual testers. I was surprised to get a response along the lines of, “Yeah…  so we can automate ourselves out of a job.”

Regrettably, there are hundreds if not thousands of jobs that are lost per year due to automation - leaving many people in a frantic to either start looking for a new job or even a career. Based off my time in the software industry I have found the opposite for QA Testers. In my defense, I delivered a handful of informal reasons on "how automated testing protects QA testers" to reassure us all that we won’t be out of a job (or career) anytime soon.

If your company is taking an initiative to implement automated testing, they will most likely seek to upgrade your skills:

Manual testers generally have the best overall view of functionality for an application. They know the areas that are most prone to breaking, understand the general flow of the application, and they work with all team members in order to ensure the application is in a production-ready state. A reliable company will see the value these individuals bring to the table and will find it worth seeking the people with the most hands-on experience to begin their automated testing initiative.

Develop more skills, putting you into higher demand:

My ability to think like a programmer has been the most lucrative skill I have obtained so far. The capability has instilled logic that has allowed me to have a more clear understanding of the world around me. I am able to make better decisions in life and take action sooner by simply understanding the philosophy behind programming and overcoming the fear of learning it. Besides, burning glass reports that 49% of all jobs paying $58,000 or more requires some form of coding skills… if that isn’t demand, then I don’t know what is.

Efficient testing leads to more productivity:

In the realm of automated testing everything is written in code, meaning that a computer will interpret a set of instructions in a static state that will be executed at the speed of light. Now the human brain is roughly 30 times faster than the best supercomputer, but the combination of neural activity with deciphering instructions and using motor skills to fulfill these instructions severely hinders your ability to be productive. Now that tests are being written in code, you can execute tests without being present, freeing up your time to assist coworkers or close out other issues.

Tests-as-Code:

This allows you to dot your i’s and cross your t’s - making you more valuable to coworkers.

Since code is static by nature, the tests you have created over time won’t change unless you manipulate your code. This innate ability allows you to scale a suite of tests covering the whole application without having to worry about writing them again unless your application changes to the point where some tests may not be the best fit. If this situation happens you may try and upgrade your suite of tests ensuring that your application stays stable on every code change.

Hopefully I have reassured some of you on automation in the QA world. I recommend learning how to use selenium -  a free open-source tool for automated browser testing. Another great source is YouTube, where you can essentially find anything and everything on automated testing if you search correctly.

Remember, automated testing is one of the greatest opportunities for a QA tester - it’ll save you time, increase your skill set, increase your test accuracy, and ultimately keep you moving forward in your career.

• Read more about Agile Scrum Methodology

We were thrilled to do a Q & A with App Developer Magazine on Agile Scrum Methodology. Check out the piece below.

What is Agile Development Methodology?

Mobomo: The Agile Methodology is an alternative approach to project management that places emphasis on collaboration, iterative development and evolving requirements. It’s governing principles, commonly referred to as the Agile Manifesto, place focus on team interaction, customer involvement and adaptability to develop high quality products.

Who uses Agile scrum development?

Mobomo: While Agile is most commonly associated with software development, it’s leveraged across many industries in both the private sector and government and is not limited to just software. From General Motors and Spotify to NASA and the Department of Homeland Security, Agile can be applied to solve some of business’ most challenging needs.

What is the process of Agile scrum development?

Mobomo: Scrum is subset of Agile development that organizes a project in a consistent process that is repeatable each iteration of the project lifecycle. The most widely used Agile practice, Scrum is ideal for managing complex software and product development as it enables organizations to more easily adapt to rapidly-changing requirements. Scrum also provides a better framework for estimating tasks and measuring productivity, thus allowing for managing the project schedule more effectively.

What are the key positions and what are they responsible for during process? (Scrum master, product owner etc.)

Mobomo: Within the Agile Scrum framework, the key positions and their role within the project are as follows:
Product Owner: The Product Owner is the main stakeholder in an Agile Scrum project who is committed to ensuring the vision of the project is reflected in the final product delivered without impeding upon the Agile Scrum process. The Product Owner assists in transcribing the product vision into well-defined development user stories and prioritizing the user stories to be worked on by the Development Team.

Scrum Master: The Scrum Master is the facilitator for an Agile Scrum Team, managing the process by which information is exchanged amongst members of the team. The primary responsibilities of the Scrum Master are to help the team determine what can be achieved during each iteration cycle, manage the daily scrum meetings, keep the team focused by removing obstacles to their progress and protecting the team from outside distractions.

Development Team: The Development Team, or Scrum Team, is a collection of individuals responsible for all work delivered to the customer. The team works together each iteration, or sprint, to incrementally deliver working components of the product.

How do federal projects benefits from using Agile scrum development?

Mobomo: Within the Federal Government, implementing the Agile Scrum methodology for software development enables the government to solicit services using more broad requirements about the tools and technologies involved the development of the desired product as opposed to specific product requirements. This allows the Development Team to evaluate the business requirements of the product as part of the contract and identify the best technical solution to meet business goals, leveraging both licensed and open-source software. Agile Scrum also provides a more structured framework that supports efficient estimation of the tasks required to deliver the product used to effectively develop an accurate project schedule.

Lastly, the incremental development and delivery of the product to key stakeholders ensures that the end product meets or exceeds the expectations of the government customer. Ultimately, the key benefit is that the government is able to get a better software product through iterative development as opposed to a software product that merely complies to functional requirements that were not completely understood at the time of the RFP.

How does this methodology help to save the government money and time?

Mobomo: The Agile Scrum methodology directly benefits Federal customers both financially and with respect to project schedule in that the project team and the customer work together on estimating the level of effort required for delivery of the project. As a team, they and are able to shape the project requirements and technical approach to fit within the constraints of the contract’s period of performance and budget. The iterative development showing product progress every week provides a high level of transparency between the project team and the customer mitigates the risk of the project extending beyond the scope of the engagement and ensures the project team isn’t developing features that do not provide value to the product.

What type of projects use the Agile Scrum Methodology?

Mobomo: The Agile Scrum methodology can be applied to any project where the development of the final product can be managed through incremental development and delivery of the product to the customer. Whether it’s mobile applications, websites, microwaves, or automobiles, the principles of Agile Scrum can be applied to achieve positive results. The most common application of the Agile Scrum methodology is for the development of highly complex software products that require both a strong process-oriented management structure and flexibility of the development team to respond to fast changing requirements.

What are some tips to start using agile scrum development?

Mobomo: The best thing an organization can do to start adopting Agile Scrum for the development of their products is to have an open dialogue with their team to share the principles of the framework and illustrates the benefits of implementing Scrum. Without buy-in from the team, it would be extremely difficult to institute such changes effectively. Next, avoid trying to incorporate all of the Agile Scrum practices overnight. Agile Scrum is a framework through which a project is managed following the core principles of Agile. It is by no means a turnkey solution that works the same for every organization, rather a set of guidelines and tools to be leveraged for impactful results. Lastly, engage an individual or organization experienced in leading Agile Scrum projects on how they leverage Scrum for their needs and gain as much knowledge as you can from them.

In order to run a project using agile scrum methodology, do you need to be certified, if so what is the process?

Mobomo: It’s not necessary for every project manager in your organization to be certified Agile Scrum practitioners, nor is it necessary for anyone within the organization to be certified. However, it's highly beneficial to have a few members of your team familiar with the principles of Agile and specifically Scrum. There is a multitude of open source documentation and training materials available to the public. For certification, organizations such as Scrum Alliance manage online examinations and membership. There are also a number of organizations that offer formal training sessions with high success rates for individuals that complete the course and the certification exam.

What advantages does your project receive with agile scrum development? What are the disadvantages?

Mobomo: The advantages of your project adopting Agile Scrum to govern the development of your products include instituting a repeatable process that seeks to continually improve each iteration of a project and beyond to future projects, promote self-organizing teams who are able to delegate tasks amongst themselves in a way that conforms to their style so long as it doesn’t encroach upon the team’s ability to deliver each iteration, and maintains transparency between the project team and the customer. Agile Scrum also mitigates the risk of scope creep and delays to the project schedule by identifying obstacles proactively and remediating them accordingly. The disadvantages of Agile Scrum are that it requires a certain degree of maturity within the organization to empower its development teams to be self-organizing, which has the potential to negatively impact a project if the team isn’t closely monitored by an experienced Scrum Master. Additionally, an Agile Scrum project requires having a healthy backlog of tasks for the Development Team to ensure no lapses in productivity occur, which is dependent upon the Product Owner having a clear vision of the product and his/her ability to effectively communicate and prioritize the tasks accordingly.

How do you organize your tasks and then prioritize within the process?

Mobomo: Within Agile Scrum, the Product Owner works with the Development Team to translate the goals and needs of the product as identified by the key customer stakeholders into development user stories. The user stories are then organized within the product backlog based on priority and underlying dependencies to identify the order in which tasks need to be worked on. After the priorities are established, the Scrum Team estimates the level of effort required to complete the individual user stories and begin organizing them into iterative sprints based on the amount of time the team has available to work in each sprint.

What happens if an unexpected task occurs, how do you organize that task within the current sprint?

Mobomo: In the event that an unexpected task is identified by either the Development Team or the Product Owner during an active sprint, the task is communicated to the entire team who then conduct an assessment of the implications, priority and level of effort involved for the task. If the task warrants being addressed immediately within the sprint, the Product Owner will determine which task(s) that were originally scoped for the sprint will be removed to accommodate the new task being included. If the task does not warrant immediate attention, it is moved to the product backlog for prioritization and inclusion in a subsequent sprint.

• Read more about User Centric Design

The first time someone comes across the term “User Centric Design” there might be confusion because isn’t all design user centric??? Arguably yes, but…

User centric design is a fairly new design concept which involves real users throughout the design process. User centric design also known as (USD)is an interface design methodology that is based on the research and the participation of the final users of the interface.

Before we dive into the advantages of user centric design lets look at the design concept that was used prior to UCD, linear design. Prior to UX and UI becoming a household concept, design projects were normally in “linear design” which meant the center of the design thought process was based on the client or stakeholder. Typically, during the design phase there are multiple teams involved which could include the client, the designer, the developer and the project manager. The only issue was each person involved had different opinions on how the design should and maybe should not look. As you can imagine not all opinions align which creates conflict between all teams. Aside from the difference of opinions, each member involved was missing what was most important- the end user!

End users are so important because that’s the whole point of creating the design to being with, right? You want to make sure that the end user’s “needs” so to speak are addressed in the design process so that the end user has the best experience possible. The problem with the linear approach is that it tends to produce products that are out of touch with the end user. Thankfully, user centric design made its debut in the design process.

User centered design (UCD) establishes a unified program of needs and goals based off of research (and not vague ideas from the team involved). The client's business and user goals are still very important in the design process however they are addressed in the strategy phase so that designers, developers and project managers know how to best guide the project based off of the goals of the client. The purpose of this approach is to create products that are based on real needs and expectations of the end user.

To outline things further, we have created a chart (below) which gives you a better understanding.

It’s always good to have a pulse check on your design to make sure its still meeting the needs of your target audience. If you are questioning the effectiveness of your design, get in touch, we are happy to chat! In the mean time, be sure to check out our UCD design process.

• Read more about SEO Guide For Drupal

A few tweaks and modules later, Drupal has easy to build SEO friendly websites. To achieve it, there are two sides involved:

Below are a few things you can do to improve SEO on your website just by working with content (texts, images, files).

Text content

Title

When you create a page on a website, the page title you decide on is used in several different places so it's important to get it right and make sure it's clear and useful.

Page title will appear:

All of above are picked up by search engines, so it's important to include relevant keywords in your titles.

Page titles should be clear and descriptive. If titles are too long to fit into a menu, or if you want to have a different menu link then the page title you could use the 'menu link title' field to display.

Drupal has a feature that allows you to specify a 'menu link title', you can find this at the bottom of the edit page form in the “menu settings” tab > “Menu link title”.

Please note, spaces in titles will be converted into dashes in the url, so do not use  dashes in titles. Maybe you could replace dashes with a colon to avoid “double dashed” urls.

Meta description tag

The meta description is the excerpt that displays under the page title and site name on the search engine's results page. If it's not filled in, the body copy will be used instead. This may lead to a cut off excerpt, but you could manually fill the ‘meta description’, or use the ‘summary’ field to avoid it.

In Drupal, the body text field on a page is accompanied by a summary field. It is important to fill this in. Sometimes, it's used on the site as a teaser to promote users to click the page and read the full copy.  Remember, it will be picked up as the meta description for the page if no meta description was manually added.

Headings

When adding or editing content to the Body, in the WYSIWYG toolbar at the top of the text field, you'll see a dropdown with a few headings options. Commonly, you will have a choice of heading 2, heading 3, heading 4, and normal/paragraph.

When starting a new section on a page, use one of the headings defined in the dropdown. Headings are picked up by search engines and will contribute to your search rank.

Besides helping out with SEO, headings are designed to draw the reader's eye so that they are able to find what they were looking for much easier. They are also useful for good content structure if the copy is long.

For SEO purposes you should only have the h1 tag used once on a page. H1 is commonly the page title.

Anchor Texts

This is the text that links to something else. For example, if I would like to point you to the about us page, then the anchor text is the (commonly) blue text you see.

Search engines compare the text written in the anchor to the link “behind” it. So if they anchor text includes keywords or phrases that will add value over time.

Anchor text is read by screen readers so it plays an important role in complain with accessibility requirements.

Please make sure that your anchor text is also descriptive.

Length

As a general rule the copy should be as long as it needs to be. Online content is not read in the same way as printed content, so keep things concise, clear and straightforward bearing in mind the user experience, not only the SEO.

As a reference, some SEO advisers recommend around 200 words as a minimum for page copy.

Files (Images, documents)

Filenames

Filenames should follow the following convention to eliminate technical problems and to improve SEO.

Filenames should be also descriptive.

Some good examples are: mobomo-logo-red.jpg, partnership-agreement-2017.pdf

Reference: https://support.google.com/webmasters/answer/114016?hl=en

Alt Text

This is a descriptive text that appears if an image cannot be loaded and is also used by screen readers. So here SEO is directly implicated with Accessibility. It's especially important if the image also acts as a link.

This text should clearly describe the image.

Filesize

Main thing you should know about files in web: Large file sizes slow down page load.

Users tends to abandon pages if the load time is greater than 3 seconds. So search engines “don’t like” to direct users to slow sites.

So, you can help to keep the page speed to a minimum by making sure the files you add are light.

A general rule is to try to keep images filesize below 70k, this sometimes is hard especially with large images (banners for example), so let’s say images should not ever be larger than 600k.  

Format

All images should be saved in jpeg format.

Documents should be saved as pdf or doc (for editable documents).

Other

404 and 403 pages

We are going to set up these pages for you, but it’s important that you fill them with accurate content given your audience. For example, you could add a link to your Homepage here or to an Archive / Search page to help your audience finding what they were looking for.

Please note these points listed above are changes you can apply without any tech support, they are just Content edits you can apply by yourself when adding / updating content for your website.

Here’s a few SEO related Drupal modules that makes developers lives easier.

• Read more about Infrastructure: Why We Love Cattle And Think Like A Rancher

Okay, okay -- we don't actually have it in for Fido here at Mobomo. In fact, we're quite the puppy- and kitty-loving group. But when it comes to building infrastructure to support your web or mobile application in today's cloud-based environment, it has never been more important to forget everything you ever knew about caring for pets, and instead, start thinking of yourself as a cattle rancher.

Pets, in a word, are unique. Aren't yours? They're cuddly, quirky, and require lots of tender loving care. And while that's delightful if your pet is a Basset hound or a Maine Coon, it's generally not the best model to follow if your pet is a server.

In the old, dark days before virtualization and cloud services, all servers were pets -- physical boxes screwed onto a rack in a data center (or worse, sitting underneath Larry's desk in the office server closet; careful with that Big Gulp, Larry!). Each one was named, crafted by hand, and given copious attention by a neck-bearded SysAdmin who came to love his servers as much or more than his children. Pets are indispensable and irreplaceable, and when they get sick, it's a BIG deal. After all, what self-respecting pet-parent wouldn't drop everything to nurse his/her little furbaby back to health?

But in the rough-and-tumble world of application development, that's a big problem. Time spent troubleshooting machine-specific problems is a deadweight loss for every project's bottom line. To say nothing of that desperate feeling when the CEO's pet project is suddenly unresponsive, and Larry's the only one who knows anything about the machine it's running on, and Larry's not answering his pager...

Cattle, on the other hand, aren't like pets. They're typically given numbers instead of names. They're expendable and (with apologies to vegetarians everywhere) disposable. Rather than being cared for individually, they are completely managed by repeatable and documented processes. If there's a problem with one cow, the herd is unaffected. The sick cow is, shall we say, simply removed from the herd and life goes on.

The advent of virtualization, cloud computing, and provisioning tools like Chef and Puppet have combined to allow technical architects to think of their resources as cattle instead of pets. This thought -- that systems are not hand-crafted masterpieces but cogs in a machine managed by repeatable rules -- is at the core of the DevOps philosophy. While there is a great deal of spirited debate over what DevOps precisely means, at Mobomo it boils down to three rules:

Infrastructure is Code

Larry's not going to like this, but he'd be a lot better at his job if he thought more like a developer. All those manual processes he goes through to create and maintain infrastructure, all those one-liner shell scripts StackExchange hacks he's committed to memory, mean he's introduced a non-automated factor into the project's critical path: himself.

But fortunately (or not) for Larry, machine provisioning tools like Ansible and Chef, along with cloud resource templating systems like CloudFormation and Terraform, mean that it is now possible to remove all manual interaction from the process and allow an application's infrastructure to be defined by code, right beside the application source itself. This way it can be version-controlled, peer-reviewed, and easily tested in non-production environments, eliminating the incongruities that come with different sets of environmental variables. Beyond that, the code functions as de-facto documentation of your environment's structure, which tends to be way more reliable than whatever is lurking in the nether regions of Larry's memory.

Bottom line: if your entire application infrastructure can't be rebuilt with the push of a button (or the running of a single shell script), then it's not in code, and therefore your servers are pets, not cattle.

Infrastructure is immutable

Related to the above is the idea that infrastructure should be immutable -- that is, never altered on the fly once it has been created. This rule prevents Larry from, say, noticing a bug and updating a configuration file on a running server, thus causing headaches the next time the application is deployed or has to scale-out. If all running resources are treated as inaccessible black boxes, this means code changes can only be made via the version-controlled provisioning scripts and templates, thus ensuring that each deployment or scale-out of the application will be running on identical servers.

Furthermore, treating infrastructure as immutable allows us to think about deployments themselves differently. Rather than deploying an application by pushing an update to run servers, crossing our fingers and hoping it works then desperately rushing to revert manually if a bug is discovered, at Mobomo we employ a Blue/Green deployment methodology.

When a production stack needs to be updated, it is deployed from scratch with new infrastructure (the "Green" instance) created from code each time. That allows QA testers (using a combination of automated and manual tests; more on the relationship between automated testing and Blue/Green deployments in a future post!) to verify the functionality of the new environment before it is made live. Then, production traffic is simply switched (by changing a DNS record or similar) onto the new/"Green" stack. If a problem is then detected with the newly deployed app, it is a simple matter to switch back to the old production "Blue" instance painlessly without the risk of extended production downtime. Once all stakeholders are satisfied, the old "Blue" stack can simply be destroyed.

Embrace the chaos monkey

Cattle-oriented infrastructure means coming to terms with the idea that failure is ubiquitous and constant, and rather than something to be feared, should be embraced. This means specifically designing your application infrastructure with the certainty that it will fail, and testing that failure constantly, in production.

We've recently been playing with a tool called Chaos Monkey created by the development team at Netflix. Chaos Monkey does one job and does it very well -- it runs in your production environment and randomly kills running server instances.

Let that sink in for a moment: if your infrastructure cannot tolerate the random, arbitrary death of machines, then you are treating your servers like pets instead of cattle.

Using techniques like load balancing, auto-scaling, and high-availability proxies, it has never been easier to embrace the Chaos Monkey. Failure should be assumed and automated procedures put in place (spinning up new machines, altering DNS and load balancer configuration) to handle that failure without any human involvement. Furthermore, with cloud services like AWS and Azure continuing to build hosted solutions that take the guesswork out of planning for scalability, we find ourselves in a brave new world in which most undifferentiated heavy lifting has been eliminated and we can focus on what we do best: building great applications.

So by all means, adopt a pet or three and care for them like family. But when it comes to supporting your Internet applications, it's long since time to start thinking like a rancher.

• Read more about JIRA Storypoints and Estimations

It's important to understand some of the advantages of JIRA as well as how storypoints and estimations relate and the best way to estimate how long it can take a team to work through different aspects of a project.

Why JIRA:

Stories vs Tasks

User stories are in the product backlog which is a ranked list of product backlog items also known as (PBIs). Stories represent the scope of the product and are identified during the kickoff with the client. Tasks can be identified during sprint planning and become part of the sprint backlog.

A user story is typically a functionality that will be visible to end users. Developing a user story will usually involve a programmer and tester, perhaps a user interface designer or analyst, perhaps a database designer, or others..

A task on the other hand, is typically something such as a code assignment, a design task, creation of test data for such-and-such, automate that, and so on. These tend to be things done by one person.

Bottom Line: A task must be written by the team and it should represent a piece of a story. I suggest we leave the tasks creation to the person who will be working on it. If this is the case we have to request to whom created the task to relate it with the story that is created. If a story was estimated in 8 hours the related task should not last more than 8 hours.

Now that we know the difference between a story point and a task let’s dive into the story points and how to estimate time using story points versus tasks.

Advantages of estimating with story points:

Why should we estimate with hours?

How to measure the story points in JIRA:

If we followed the above steps we could have the following in JIRA:

Velocity Chart:

A velocity chart is a graphic representation of what the team was committed to do and what was actually completed along sprints.

After a few sprints the velocity of a scrum team will most likely be predictable and will show the accurate estimation of the time needed until all entries in the scrum product backlog will be completed. If the velocity of a scrum team is e.g. 50 story points and the total amount of remaining work is 220, we can predict that we need about 5 sprints to complete all stories in the backlog.

Tip: See how the Story Points and Completed Stories get increased in time. This is because the team is going through a learning curve satisfactorily. In this case the dev team completion average is 40 Story Points.

What does a velocity chart represent?

The velocity chart shows how the team is performing during the project. What we expected is exactly what the graphics shows above in an ideal scenario. Therefore we can notice which team performs better than others and who individually inside the project is not performing as much we want.

Scrum Burndown Chart:

The scrum burndown chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release.

Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule. As a definition of this chart we can way that the burndown chart displays the remaining effort for a given period of time.

General breakdown of the burndown chart should consist of:

• X axis to display working days
• Y axis to display remaining effort
• Ideal effort as a guideline
• Real progress of effort

The biggest lesson we have learned is that you should not equate story points to hours in JIRA. Even though you know that a story point is closely tied to effort and effort equals time. It is important to realize that you should not equal the two.

• Read more about Working With Hybrid Teams

Including Offshore Teams in Your Workforce

Over the last decade, more and more U.S. based organizations have been working with offshore teams. The pricing for offshore development is very compelling, however, sometimes delivery, and consistency can oftentimes be an issue. Here at Mobomo, we have solved this issue by presenting clients with the option of working with a hybrid team versus strictly offshore or strictly onshore.

Mobomo has a top of the line onshore project management team- these folks are versed with leadership qualities as well as project management skills that can ensure on time deliverables. Some of the benefits of a hybrid team is that your project is being worked on around the clock, which ensures a quicker delivery date. Having U.S. based staff in these leadership roles helps the coordination of the project between the client as well as the development team.

Our project managers sync daily with off shore resources to ensure that items on the to do list are being accomplished as well as to make sure that everyone is on the same page. Going over tasks completed yesterday, what they are planning to do for the day as well as if there are any questions or blockers. When project managers connect with our development teams this is the time that ensures that there is no miscommunication.

Below are a few things that we incorporate into our framework of working with our offshore team.

Sprint Planning

• This occurs the first day of sprint and could take an hour. Typically, we conduct sprint planning with our development team to ensure our deliverables match with our timeline. We use JIRA to review desired tickets to complete, and estimate the level of effort to ensure we have enough time to complete all tickets in the sprint. The team self-manages who will work on what throughout the sprint.

Daily Scrums

• We hold a 15 minute conversation to review the prior day’s completed tasks, which tasks need to be completed that day, and any blockers or questions the team may have. The team self-manages who will work on what task each day. We also review any additional agenda items as needed based on the project such as updates or questions from the client, scope changes, etc.

Review Daily Status Reports

• Our offshore team sends an end of day update (morning U.S. time) which consists of a daily summary of tasks that are ready for review, as well as tasks that are still in progress. We download the latest build and test the updates daily, provide feedback as needed, and/or close out completed tickets.

Sprint Review: last day of sprint (~1 hour)

• It’s important to review a completed project or sprint as a team once that sprint is completed. Some of the bigger questions in this review are understanding what worked well, what should the team do differently next time. We call these meetings retrospectives. Our teams find it useful to do a scrum retrospective so that we can find ways to improve based on what went well and what needs to be reviewed for the next sprint and or project. You can see a full analysis of how we run a sprint review here. 

Aside from the framework of how to work with an offshore team, it's important that the project manager has the ability to communicate well with the client as well as the offshore team. Internally, our project managers use Zoom, Google Hangouts, and GChat to have direct conversations with our offshore team to walk through all assigned tasks as needed. Direct communication with all team members ensures everyone is on the same page and opens the floor for immediate resolution of any questions the team may have.

• Read more about Design Trends For 2017

It's crazy to think that 2016 is coming to a close, the question is what will 2017 bring? At Mobomo, we strive to think ahead and implement cutting edge trends so that we are always ahead of the time. Now the question is what is the “next big thing?.” Unfortunately, as far as we know there is not a way that anyone can truly predict the future, but what we can do is look at current trends, as well as past trends to get a sense of what the next year may hold. Below we have listed out some of the design trends that we predict to see in 2017. This list is by no means a definitive one, but our design team is keeping a close eye on these as we ring in the New Year.

DESIGN TECHNIQUES

Minimal/Flat Design - This one is not going anywhere, and as far I as I can tell it’s really only getting stronger. It does make a lot of sense that this approach to solving a creative problem used quite frequently. We are bombarded on a minute by minute basis with new content and information to the point that we literally can’t digest it all. By handling your content in a “minimalistic” way you’re helping the people that use your product by removing any clutter. There are no extraneous steps they have to wade through.

Soft drop shadows - Another technique that has only been getting stronger is the use of “pillowy” drop shadows on web and app components. For me, again this makes a lot of sense, if used appropriately it doesn’t take away from the “minimal” look of your site, but rather adds a layer of depth to it. Adding depth to your product can do several things, A.) It can show hierarchy in your content by literally elevating it above other items, B.) It can be used to show hover or active states of your content, and C.) Depth adds a level of visual interest that helps to break up the flow of the page, make the content more digestible.

Non traditional/breaking the grid - Breaking the design grid has always been a strong technique when implemented correctly. What it does is break up otherwise static content into interesting visual cues. It’s one of the best ways to “surprise & delight” the people using your product, to unexpectedly alter the layout in a manner that makes them stop and absorb what they are looking at.

Organic shapes - The use of non rigid, more fluid shapes within a product or site helps to break away from the pack. By slightly altering a button, or header graphic to something softer than a square, you begin to give your layout a completely different feeling, something much more approachable.

Large Text  - Large, powerful, font choices will continue to increase. Especially as the amount the content grows, there’s has to be a way for copy and text blocks to stand out. Gone are the days when a 12pt font is an acceptable choice for web copy. With the increase concern of accessibility and usability becoming the primary business goal of product owners, larger fonts equal easier digestion of content.

Bright colors- As the need to standout becomes more necessary, the more we will see websites and applications use bold, bright colors do that. The use of strong colors helps to create the type of visual tension that people like when using your product. It helps to quickly reinforce key information and page components like buttons.

Experimental prototypes - While designers continue to push the limits of devices and people's expectations, there will always be a place for experimenting. While these might not be quite ready for the mainstream public, they do show where the future of applications and websites are headed.

Futuristic interfaces - If the demand for products like Nest and Tesla continue to climb, so will the interfaces that accompany them. Some of these might still be experimental in their perceived execution, but again they show where consumer based interfaces are heading.

Web forms

As peoples attention is increasingly being pulled in many directions, the way we expect them to enter data and communicate on the web has to accommodate that. There has recently been a surge in “bot” based communication on the web and in apps, where people communicate back and forth with the product in a very natural, conversational way. I think 2017 will only see this new form of interaction increase and become more adapted.

Beyond design techniques, I think we should be on the look for more applications like Adobe XD and Figma that allow multiple users to work across a single project without the need to handoff project files. We can see 2017 being the year of collaboration based tools, where teams begin to work more fluid across several projects with several designers helping out.

Let us know what you think 2017 has in store for designers!