An inside look at our Design Teams’ Remote Collaboration

Design professionals today are not confined to office spaces for design thinking and execution. Teams don’t have to stay in proximity to deliver the best design work. This is an era of remote working and even with team members located across continents, companies need to keep up the flow of creative innovation.

Design Team Collaboration in Commonly located Spaces

Remote working in regards to design projects is not a cakewalk as the value proposition depends on collaborative design sessions and team cooperation. Challenges like juggling through time zones, scheduling meetings, communication breakdowns, bad collaboration, etc., keep the designers on their toes.

Design projects are tricky. The bigger they get, the more complex it becomes to track activities and prompt the designers to get the tasks done. When it comes to remote collaboration, it doesn’t get any easier as designers can’t interact face-to-face. Given the illustrative nature of the designing, designers are supposed to work shoulder-to-shoulder and be able to draw, point, note, and gesture to get the work done.

At first, it seems like these tasks don’t fit well into a virtual teamwork setting. But that isn’t true. In the last few years, prevalent cloud technology has made remote collaboration smooth and sought-after by design agencies. So much so that it has redrawn the employee structure across companies.

How our Design Teams Collaborate Remotely

Our designers use cloud technology, multimedia, internet communication, and an array of cutting-edge technology tools. They partake in design sprints, brainstorming activities, face-to-face team interactions, and constant exchange of feedback and suggestions.

We use a structured and transparent communication setup that helps us navigate through the glitches of remote collaboration. Our communication spectrum goes from asynchronous and text-based communication to video conferencing. Our design leaders effectively discuss the action plan with the team, including what each unique team member is supposed to do, and by when. On the plus side, this helps foster a symbiotic practice and a sense of camaraderie among Galaxy’s design staff.

1) We count on the best collaboration tools:

Whether working remotely or in-person, sharing designs and gathering feedback are the most important facets of design validation and prototyping. In the process, the possibility of small details being overlooked and context being misunderstood remains. To avoid that, we employ Slack— a well-crafted collaboration platform that supports audio and video calls, all kinds of media file transfer, and integration with other tools. This makes our communication transparent, fast, and smooth.

Slack: Slack is our meeting room, notice board, water-cooler, call tree, and news broadcaster. It accommodates both team and one-on-one communications. It is a fun and all-inclusive alternative to monotonous email and messaging options.

2) A single, co-owned repository to tell us the work in progress:

Remote work setups are prone to confusion and miscommunication. Too many information repository tools only add up redundancy and confusion. We use Confluence to centralize all the technical documentation and progress of the projects in motion. For every step in design, an entry is illustrated with commentary, screenshots, and comments. This is to make sure everyone is on the same page, speaking the same language.

Confluence is a wiki for team collaboration. Team members can create, share and receive information about any ongoing project. As soon as any development takes place in the project, it is updated in the confluence knowledge base and becomes available to the team members.

3) We organize FREQUENT online meetings:

Remote teams don’t get in touch before a teething problem turns into a quandary. But design teams at Galaxy hold virtual team meetings thrice every week where we chew over design challenges, and fix them while they’re still manageable. Our intra-team meetings are complemented by impromptu pairing sessions where designers find themselves brainstorming with programmers, business developers, and documentation teams.

Zoom: For intra-team communication, we typically use a combination of video conferencing tools including Zoom. Conducting virtual meetings is fun with Zoom, which allows a participant count ranging from 7 to 70. From joining meetings midway and toggling between participants to sharing screens, Zoom accommodates it all.

4) Show, don’t tell:

Asynchronous and text-based communication (telling) becomes intricate in big projects. Showing, on the other hand, is more powerful than telling and visual inspiration goes a long way. Thus, we prefer using online whiteboards, sending screenshots and snapshots of plans, paper prototypes, sketches, personal notes, etc. When words fall short in conveying design nuances, screenshots and pictures do the job effortlessly.

InVision Freehand: Freehand, a feature of InVision, is a new, exciting, and creative way to collaborate in real-time. InVision Freehand features tools like Draw, Write, Sketch, and Comment as well as a lot of other functionalities. We use this tool for planning, feedback, and design presentation purposes. Freehand is a virtual whiteboard for us and any team member regardless of the location and can contribute to the ideation and other processes through this tool.

5) We keep a check on our competence as a team:

When working remotely, there’s a concern about how the efficiency and productivity of remote teams can be measured.”

It’s a lot easier than measuring efficiency of co-located teams. Organizations having remote work culture are result-oriented by necessity. At Galaxy, we draw clear work goals and deadlines. There are indicators like— reached budget, extra work hours, timely delivery, adherence to the task backlog, client feedback, etc., to measure performance. We also calculate the efficiency by calculating the progress of teams/individuals in prioritized tasks in the given time frame.

Trello: In Trello’s own words — “It’s a collaboration tool that gives you a visual overview of what is being worked on, who is working on it, and how far they’ve gotten.”

Simply put, Trello is an online corkboard, allowing users to enlist tasks, projects, files, resources, and everything else needed for working together. It is designed for task-based communication, and we use it as task calendar, checking off completed tasks and scrutinizing what is in motion. We use Trello for Value Stream Mapping of all our projects and processes.

In conclusion, we would like to leave you with some tips:

  • In the context of remote working, what works for one organization might not work for others, so experiment with pilot efforts.
  • Like a co-located environment, have an organizational structure for remote teams.
  • In a remote team setup, there should be one key person who owns the project and is aware of all the progress. 
  • Keep up with with new communication software and technology features. Don’t try to use them all — pick and choose just a few that best suit your team.
  • Set goals and deadlines the same way you would have if the teams were co-located.
  • Giving your team the freedom to be innovative and experimental with their work will have a positive impact on your business.

Remote Collaboration between Design Teams Infographic

Hamburger menu | To use or not to use

Even though it might seem like a contemporary design element but Hamburger menu is as old as our personal computers. It was designed by Norm Cox, design lead for the first ever graphical user interface made for Xerox Star.

Since then Hamburger icon has become synonymous with menu and a way to make the screens clutter free. Almost all of the internet recognizes it as the menu icon.

But as ubiquitous as the hamburger is, it is not going to stay that way. Here’s why

Makes feature discovery a task

Practically every designer has used hamburger menu as a goto navigation component. What a lot of people miss is the fact that it’s hidden and whatever is out of sight, is out of mind.

It’s proven that using hidden menu adds to the friction and user would rather skip than go through the difficulty of revealing and discovering hidden features.

Besides, people are more likely to use visible navigation than a hidden one.

Conflicts with system navigation

When smartphones sacrificed the capacitive and solid buttons for screen real estate, on-screen and gesture navigation had to make their way in the UI.

iOS apps have been struggling with hidden navigation long before no-buttons-all-screen went mainstream. Designer can only put so much in a navigation bar. It’s either menu or back button for navigation because none or both are a bad option for usability.

Non-glanceable

Adding a layer of difficulty just so that interface looks cleaner is bad for engagement and conversion. Visible menu such as tab bar lets the user see right away what’s what. It also makes notifications more contextual.

People find it easier to switch between tabs than discover hidden features via menus.

It’s just like choosing what to order when you’re hungry. What are you more likely to order, a dish for which you can see the ingredients for or a dish for which you can’t?

The former, of course, nobody likes to experiment on an empty stomach.

Now that the hamburger is out, what are your options

Tabbed navigation

This menu is prominently used in mobile phones. Smartphone screen sizes have increased substantially and single handed usage has become more difficult than ever. The hamburger which was easily approachable once with smaller sized screens is now even out of the stretch zone of the palm.

Tabbed navigation at the bottom brings the navigation down where everything is easily reachable within the reach of your thumb.

If you look at the Android UI Guidelines you will find that the Tab Bar is now a main navigation component. Which means that it’s more suitable for current and upcoming devices.

Progressively collapsing menu

This is a progressive approach towards hamburger menu. But unlike hamburger, this navigation adapts to screen size without hiding the features.

This menu utilizes familiar iconography to collapse the navigation according to the screen size without losing much information.

Combination of tab and hamburger

Combination menu comes in handy in the scenarios where the design calls for more than 5 menu items. Phone screens are big but they can only be as wide as the grip of the palm. There is no way to accommodate the amount of items that a hidden menu can house.

A combination menu has four tabs and a hamburger to house more items.

Takeaway

Hamburger menu has its share of good and bad. A bad implementation doesn’t necessarily mean that the UI component is bad. There are apps where hamburger makes for an ideal choice and in other cases it causes friction in user experience.

It all boils down to what’s more suitable for your app or website. Any of the hamburger alternatives will work for you as long as it’s not hidden.

Why it’s a bad idea to ignore older adults from your app demographics

Modern technology has two problems: Devices have too many integrated features and everything is smaller.

A good implementation of more-than-what’s-necessary features can give some users an all-in-one experience. While a bad implementation can make it a nightmare to use for an often ignored demographic which is older adults.

Who exactly are these older adults:
Older adults are users aged 50 years and above. The learning curve isn’t that smooth for this demographic as compared to millennials or Gen Z.

UI that has too much going on with it often confuses older adults and they tend to blame themselves for not being able to use technology rather than the design.

But, one can’t put their lives on hold just because of their age. It’s simply a question of need. If they can go to YouTube and learn how to make a cake then they can also learn how to get a cab with Uber.

Infact, generational stereotypes are getting out of the way while building app interfaces for this demographic. As this cohort is not so far behind when it comes to using Facebook, Uber, WhatsApp or YouTube.

Myth #1 Targeting old users deemed as being the last Internet frontier

Video of Snapchat dog filter

Attracting older adults as part of the user-base was considered to be a niche market. Maybe ageing adults aren’t the target of Silicon Valley’s latest service or dating apps but startups believe there is value in addressing the elderly’s needs.

San Francisco-based company Honor (custom home care for seniors) has recently closed a Series C round. It has raised a total of $115 million in funding in just four years.

Myth #2 Elderly do not want to use modern technology at all

It’s not like they don’t understand technology and associated benefits. They want to use the tech but it’s targeted towards and tailored for younger audience. Besides older people are the ones who face trouble getting in a car and driving to get groceries or medical supplies. They need these apps as much as any other group of people.

Martin Gerstell, 94, volunteered at the National Gallery in Washington last month, used the Uber app his granddaughter installed on his iPhone.

Why should older adults matter to designers?

Man on a DJ console

From getting into the swing of mobile phones and computers to watching monologues of the late night show on YouTube or owning a fitness tracker, for decades people aged 50+ have used digital technology in one way or another.

  • Almost 70% of old people all over the world today have some sort of internet exposure on a daily basis.
  • According to the census report, by 2030, about 20% of the U.S. will be old.

The number of older netizens using smartphones is significantly more than ever but contemporary digital products continue to ignore and fail this demographic.

As Don Norman observed, bad design abounds, in both digital and physical products. Current interaction designs often feature startling sounds, tiny targets, illegible text, and other features that make the online world unfriendly to older users.

Good design for older adults is often recognized as good design for everyone

It’s worth giving a thought that when you’re designing for maximum accessibility you’re automatically designing something that is engaging and easier to use. Design guidelines below are consistent with the principles of Universal Design in most of the big enterprises.

  • Distinguish the primary buttons from their surrounding UI elements by proper pairing of color, contrast, layering, shadow and highlights.
  • A simple navigation is essential to allow users to easily and quickly get from point A to point B. Flexible patterns like grids, minimizing sublevel, keeping menus in a single function, etc. are among today’s best navigation practices.
  • Button and text sizes should be kept scaled up. Like keeping icons labeled with bigger text whenever possible or preferring Sans serif typefaces for on-screen readability.

Feeling bogged down while designing an ideal interface for this ‘optimistic’ crowd? Start a project with us for creating an inclusive experience that’s unique and accessible at the same time.

5 mistakes to avoid while designing tooltips

Tooltip is a great UI pattern for user onboarding and feature discovery. But there is a thin line between useful and annoying tooltips. This post will help you draw the line.

Your tooltips are either helping users by telling them about the features that are exclusive to your product or they are interrupting users in between their important tasks to tell them how brilliant your new upload feature is. It’s a mistake to question your user’s intelligence. Tooltip design often fails because of common mistakes like these.

Here is a list of 5 mistakes that you can avoid to boost feature adoption and product tour completion rates with your tooltip design.

1. Where are the hints when you need them the most!

Image of a man acting confused in a shopping mall

One of the most frustrating things about tooltip design is visibility. While designing unique interfaces, placement and size of tooltips are often ignored. A user can’t use something if it’s hidden.

Most common implementation of transient tooltips doesn’t take touchscreens into consideration. Hover triggers have tiny hit points. Anything tiny is bad for accessibility. These actions require fine motor skills to land and hold on the hit point for a while.

2. Must have one upper case, one lower case, special char….poof!

Ant Man shrinking

Consider tooltip as friction in user experience, if the users have to go out of their way to perform a difficult action, chances are they’ll skip.

If the interaction in your design requires a lengthy explanation, then tap or hover to reveal action becomes an unnecessary burden.

3. Oh! Here is a tooltip telling me to write in the field it’s obscuring

Lady running through kitchen

Some transient tooltips are designed to expand over the input field while some stretch past smaller screens. You can’t read and act simultaneously when the tip is inaccessible or covering the input fields.

Tips are supposed to help the user with the interaction and not obstruct it.

4. Should have told me earlier that tapping this button will terminate my session

Train pilot emergency breaking

Timing is crucial in tooltip design. The tips should be aligned with the user flow. Feature adoption and user’s understanding of your product depends on the relevance of tips and not the frequency of it.

A user will only be interested in reading about a feature when they need to use it. Overwhelming the user with information for the sake of feature discovery will only make them skip the info.

5. What does it have to offer?

Last but not the least, comes your tooltip copy. A boring and irrelevant copy might cost you the user motivation to even encourage an action. Motivation, Ability, and a Trigger are the three crucial elements in BJ Fogg’s Behaviour Model that prompts a user to take an action.

Copy is an indispensable part of a tooltip because it motivates the user to take action. Your tooltip is doomed to fail if your copy isn’t conversational or it doesn’t reflect your value proposition.

In a nutshell

Even the most intuitive UI needs tooltips while onboarding new users or introducing new concepts. The difference between not-so-obvious and obvious is not that obvious. Think about your target users while making these assumptions. Explaining a basic feature to an experienced user might annoy them.

Facebook, Asana, and Slack are some of the best examples of great tooltip design. Their tooltips are a part of the user flow. Facebook has a subtle, conversational, and attractive approach towards tooltips, which informs and encourages action as well.

If you’re seeing significant drops in your user onboarding or feature adoption then give us a shout here, we’ll be happy to help you optimize your tooltip design.

Unboxing popular PWAs | Techniques used and impact

What is common between Pinterest, Tinder, Uber, Trivago, and Airbnb?

All these companies experienced a surge in their product’s performance, user-engagement, and conversions by going mobile-first with progressive web apps.

Why did they go for PWA you ask? Legacy websites of these popular platforms were doing good for big screens but not so much for the small screens. Considering the ever increasing growth of mobile users and loss of potential market they decided to prompt users towards their native apps.

After seeing people bounce from their native apps too, they decided to go with progressive web apps.

This blog covers progressive techniques that Pinterest and other major companies use to build PWAs.

Pinterest reduced its Javascript bundle size via Route-Based Chunking

Code-splitting reduces time to interactive by loading only the code that’s needed beforehand while the rest of the code loads lazily.

Pinterest broke-up & shaved hundreds of KB off their JavaScript bundles weighing 650kb. Pinterest split it’s multi-megabyte JavaScript bundles into 3 different categories of webpack chunks (Vendor, Entry and Async). They used webpack’s CommonsChunkPlugin (replaced with SplitChunksPlugin in webpack v4) to break out their vendor bundles into their own cacheable chunk and added React Router for code-splitting.

As a result, Pinterest was able to take down the size of their core bundle from 650KB to 150KB.

Uber and Tinder also took a similar approach and….

  • m.uber comes in at just 50kB and loads in less than 3s.
  • Tinder took down its core bundle size from 166kb to 101kb and reduced its load time from 11s to 4s.

Faster loading for Tinder and Nikkei via Inline Critical Path CSS

The bigger and more css files you have, the longer the page takes to load. Inlining critical CSS eliminates Render-blocking scripts.

Tinder used Atomic CSS to create highly reusable CSS styles to inline all the critical CSS in the initial paint. Tinder used Google Analytics and CSS stats for each release to keep track of what has changed. It saw change in average load times went from ~6.75s to ~5.75s. Thus, removed critical CSS from their core bundles.

Nikkei, a Japan based media business, inlined all the critical CSS with 0 render blocking stylesheets. This optimization helped Nikkei to reduce its first meaningful paint by more than 1 second.

What else can you do besides code-splitting and inlining CSS?

Asset caching via Service Workers

Service worker is a lightweight net proxy which allows web applications to cache all of its necessary resources to load substantially faster for returning visitors. Essentially, it helps in caching main JavaScript, CSS, and static UI assets.

One way to generate a Service Worker file and a list of assets is via Workbox Webpack plugin. Many web applications take advantage of Workbox Webpack plugin for network resilience and offline asset caching. That further has helped these companies to speed up Time To Interactive on repeat visits and first meaningful paint.

Treebo saw 31% improvement in TTI and loaded in under 4 seconds, whereas Pinterest reduced its TTI from 23s to 5.6s.

You can refer to Google Offline Cookbook for other caching strategies.

The Future

Making speed one of the core metrics is an important step towards delivering a hassle-free and cutting edge experience to your customers. More and more websites are opting for an offline-first web. It’s only practical to adopt the ‘write once and use anywhere’ approach against writing natively for every other platform.

Google and Microsoft are also working towards a future where PWAs are available alongside full-fledged apps in app stores. It’s safe to say that PWA is in fact the future of the interwebs.

Progressive techniques can give your website a much needed performance boost like these apps that you just read about. Thinking about making the move to PWA? Talk to us here.

Kotlin 1.3.50 | More than just a performance upgrade

Kotlin has emerged as both substitute and supplement to C++ and Java. In 2018, the language had over 96,000 repositories on GitHub and had already reached 1.5M+ users.

More than 50% of professional Android developers now use the language to develop their apps. Google claims that this figure will increase dramatically. Since in future Kotlin will be the first to receive new Jetpack features.

The new Kotlin 1.3.50 release kicks off with various tooling and quality improvements to develop applications much faster. Let’s take a look at the major improvements from this release.

Convert Java-Kotlin with fewer compilation errors

The one-click Java to Kotlin converter tool helps to convert an existing Java project, one file at a time. The converter is not meant to produce 100% error-free code, instead it’s built to reduce compilation errors.

The converted code might show nullability issues that require human intervention. Manual corrections fixes the code for the time being but it doesn’t foolproof the code from runtime errors that show up in the form of nullability mismatch.

The new improved version of Java-to-Kotlin converter (available in preview) tries to infer nullability more correctly based on the Java type usages in the code. And helps in making it easier than ever to convert code with fewer compilation errors. The generated Kotlin code is easier to manipulate too.

Improved Debugging

Bytecode has a lot of technical information and displaying all of that can make the code bulkier and unreadable. Kotlin ‘Variables’ view now highlights only the most relevant variables, which aids in easier debugging.

  • You can set a breakpoint inside lambda expression or at the end of the function as well.
  • Improved support for the “Evaluate expression” functionality in the debugger for many non-trivial language features. You can now modify variables via “Evaluate expression”.

New Intentions and Inspections in IntelliJ IDEA

This addition helps in learning how to write idiomatic Kotlin code, improve performance of IDE actions, and fix several known situations that were causing the UI to freeze.

  • IntelliJ IDEA now highlights deprecated imports from the completion list
  • You can convert normal properties to lazy properties and vice versa
  • You can automatically replace the primitive lateinit property with the by Delegates.notNull () syntax

Kotlin/JS now supports Dukat-Gradle integration

Dukat is a converter of TypeScript definition files to Kotlin declarations. By running the build task in Gradle, typesafe wrappers are automatically generated for npm dependencies and can be used from Kotlin.

You can now comfortably use the JavaScript ecosystem libraries in Kotlin in a type-safe manner without the need to manually write wrappers for JS libraries.

Other Kotlin/JS updates

  • Incremental compilation for Kotlin/JS is now up to 30% faster compared to 1.3.41.
  • Support for running and building Kotlin/JS Gradle projects using the org.jetbrains.kotlin.js plugin on Windows.
  • As with other platforms, you can use Gradle tasks to build and run projects and resolve NPM dependencies needed for Gradle configuration.

Kotlin/Native updates

Earlier version names of Kotlin and Kotlin/Native differed from each other. This release uses version 1.3.50 for both Kotlin and Kotlin/Native binaries, reducing the complexity. As the standard library updates to support the kotlin.reflect.typeOf() function for Kotlin/Native types.

  • Kotlin Native now ships with an exhaustive set of platform libraries on macOS/iOS and embeds actual bitcode in produced frameworks.
  • Kotlin-platform-native is now replaced with Kotlin-multiplatform

Here’s a link to the change log if you’re curious about the other features that are packaged in the Kotlin 1.3.50.

Let us know how you feel about the multiplatform Gradle plugins and handling nullibility errors manually. And ping us here if you need Kotlin development assistance.

Galaxy Weblinks Ranked Among Best Web Developers on Clutch

When you think of hotspots for tech, don’t zero in on Silicon Valley just yet. According to Expert Market, Boston is one of the top 10 tech cities in the world, and Galaxy Weblinks is proud to call it home. We’re thrilled that Clutch, a business services resource, has recognized us as a top web developer, with an average client rating of 4.8 stars. We’re committed to offering accountable web development, and we take steps to ensure that each project we take on receives the resources it needs. All of our clients love that we have dedicated project managers for each project. This ensures proper communication and updates that help our clients be on top of things. In one such project, we developed an e-commerce site for Fast & Light LLC, a digital marketing agency. We tailored our deliverables to meet their specific design requirements.
A screen capture of a review
The delivery of the website improved the agency’s internal efficiency by freeing their teammates for other tasks. They were happy to work with our team and found our resources friendly and easy to get along with. We redesigned a website for another highly satisfied customer, a women’s clothing boutique. We worked in Magento to improve inventory details and make links more accessible, along with a more intuitive UX.
Screen capture of a review
We delivered the improved website in just a few weeks, and our customer was happy with its functionality. We also explained our process and worked with their feedback throughout the project cycle. “They were able to put my ideas right into place on the website and then immediately asked me for my feedback. The job got done so quickly and for such a reasonable price that I was extremely surprised.” – Owner, Women’s Clothing Boutique We’re thrilled to receive such praise from our design and development clients. Getting validated reviews from clients just goes to show our credibility. We love that Clutch was able to help us with it. We are a versatile software development company with strong core values. We believe in a world that intersects & interacts with software, we are focusing on building it as human as possible. You can also review our profile on The Manifest, a guide to B2B services. We’ve been ranked among the top 50 developers in India, our second location. Potential customers who would like to visualize a project can also see our work on Visual Objects. Many of the tools and platforms we’ve built are shown there. Interested in our work for startups as well as larger businesses? Contact us

Product tour lessons from Disneyland | What keeps you asking for more?

The experience of Disneyland is always an awe-inspiring one. No matter how many miles you have walked, you are always up for another Pirates of the Caribbean adventure or Space Mountain ride for the last time before you leave. No wonder Disneyland has become the epitome of mass engagement. Your product tour can also leave a similar impression on user if done the right way. Of course, we are not suggesting to go about building theme parks, that’s not a practical advice. But we can draw lessons from Disney’s ‘Happiest place on earth’ when designing product tours.

Ensure a shortest possible journey to the ‘aha moment’

A picture of Mickey Mouse and
Image Credits: Peter Lee
The ‘magical’ moment when the user realizes your product’s value is often expressed as ‘Wow’ or ‘Aha’ moment. Early realization of the ‘Wow’ factor of your product gets user’s undivided attention. All because you valued their time and have aligned your product tour to their requirements.

Leverage small details for superior user experience

You don’t have to hold on to your trash for long when roaming on Disneyland’s streets. There is a trash can present at every 30 steps. The reason being, visitors tend to discard their trash before that, as observed by Walt Disney. Thoughtful details like these make for a great user experience. Some of the ‘trash can’ examples in product tours are:
  • Option to pause and resume tutorials
  • Option to exit a feature preview
  • Positioning hotspots for minimal distraction
  • Progress bars to be present

Use multiple channels of engagement

Picture of Fireworks at Disneyland castle
No one gets bored in Disneyland. The reason being that there is something for every visitor. The key is to keep the users engaged. Increase user-engagement by introducing ‘meet and greet’ for new features, options for personalized interactions via in-product messaging, or a short product video. Keep the options open for your users as well. Let them decide how and when they want to know more about your product.

Pitch your tutorial with a story

Statue of Walt Disney with Mickey Mouse in Disneyland
Stories have the element of emotion embedded in them. And emotions are the golden path of connecting with your users. Tell your growth story through a short video, or highlight common problems that your product solves. Usage of visuals will evoke emotion and tug the user to explore more of your product, just like you’re drawn to the emotional element of Disney movies even though the whole premise is CGI.

Maintain a theme and brand image throughout

The areas in Disneyland, all have their own thematic music, characters, and pavement designs. Your product tour should also be consistent with your app and website theme. Consistent theming will help in easy recognition of your product in crowded market. Core values highlighted in your tour will set the precedence for building your brand. We know it can be a daunting task to get users to interact with your products, the way you want them to. Let the product tour highlight the fundamentals of your product and leave the rest for your user to discover on their own. Just as we love to explore Disneyland by our own preference and pace. We actively work on aligning these principles with our client requirements to design unique and high yielding user experiences. Get in touch with us here if you’re looking to design an engaging experience for your product.

What are Google Play’s new mobile app requirements?

Google Play set out many criteria in their app guidelines that you need to follow. These changes may cause some issues as you try to stay up to date. In this post, we’ll tell you what changes you need to make in order to guarantee that your app is fully compatible with Google’s new requirements.

Google made changes to the behavior of the API to increase security and privacy. The bindService() implicit intents in Android 5.0 aren’t supported currently. There are also new changes in the Runtime permissions. Since every Android app runs in a reduced-access sandbox, so the app has to ask for permission when it wants to use materials or information outside that sandbox. Google Play asks that you state the need in the app manifest and then you have to approve each permission right before the actual runtime.

This permission change is for Android 6.0 and higher. You can still use the Android Support Library to make older versions of Android compatible. Google Play also updated the Android Support Library with the release of Android 9.0 (API level 28); the new version is called AndroidX and is part of Jetpack. The existing support library still exists with the AndroidX library, but it also includes Jetpack’s most recent components.

Google Maven holds onto all versions prior to API 27 and Google Play says that they’ll be packaged as “android.support.” But, all new development will take place on the AndroidX library, so Google Play recommends that you develop new projects here. If you have an existing project, they recommend that you migrate it over.

To further increase secure connections, Google Play has changed the user added CAs to not be trusted by default in the case of Android 7.0. They also require explicit user approval from apps to access the user account in Android 8.0.

For MetaData, Google now has a small MetaData on top of each APK so that each app release is officially verified by Google Play. They don’t allow apps with any deceptive, incorrect, or explicit metadata that isn’t pertinent to what the app is about. This entails every area of the app — the title, description, all images, and icons. They also don’t allow user testimonials in the app’s description any longer. Authentication is important for users to know that an app is legitimate, so they’re spending time to ensure that each app functions as advertised.

Here Are Google Play’s New Requirements for Texts & Images

Google Play store now allows 2–8 screenshots for each supported device, i.e., smartphones, tablets, Android T.V, Android Wear, etc. But, to publish your store listing, you have to upload at least two screenshots for each device type. It needs to either be a JPEG or 24-bit PNG (no alpha) with minimum dimensions of 320px and maximum dimensions of 3840px.

Screenshots aren’t the only images that need to be formatted. Google Play requires one splash screen for an iPhone display and one for an iPad display, both retina and non-retina displays. Whether you’re using a photo or video, dimensions should be 1024px by 500px. If you choose a video, make sure to use an individual video’s YouTube URL, not a YouTube playlist or channel URL. The video shouldn’t be longer than two minutes.

Google Play now requires icon images to fit into the new, standardized icon shape — the square with rounded corners known as a “squircle.” It needs to be hi-res, material icons used through Android M, and adaptive icons for Android O.

For your text:

Titles – Should be between 4 and 30 characters – But, the new limit was moved from 30 to 50 characters

Descriptions – The short description has an 80-character limit – The detailed description has a 4,000-character limit

Keywords – They’re required and the new version has a 500-character limit – Users can also fill in this field while updating the application version

Before Launching, Follow Google Play’s Checklist

Key Takeaways

  • Google Play changed API behavior
  • Android 5.0 implicit intents are no longer supported
  • Android 6.0 and higher has changes in Runtime permissions (app must request permission of a material, then approve permission before runtime)
  • Develop new projects on AndroidX library
  • There is now MetaData on top of each APK
  • There is new length requirements for, Titles (new 50-character limit), Descriptions (80-character limit), and Keywords (500-character limit)
  • There are new requirements for images
  • Icon must be the square with rounded edges — aka a “squircle”
  • Two screenshots per supported device type (smartphones, tablets, etc.)
  • One splash screen for iPhone and iPad screen displays
  • For videos, link to an individual video, not a playlist

Good Luck on Your Launch!

Galaxy Weblinks stays up to date on these developments so that our clients don’t have to do time-consuming, detailed research. That’s why our clients love partnering with us for mobile app development — we don’t leave them in the dark nor overload them with lengthy information. We provide overviews, outlines, and how-to guides so that clients can feel confident when updating their app.

Feel free to use our above checklist to keep yourself on track. If you have questions about this process, leave us a comment or contact us. If you have questions about other app topics, then browse our blog!

The Bare Bones of Skeleton Screens

Losing customers to Slowpoke of a UI is a nightmare for any UX designer. What if there was a pseudo-catalyst that could make your UI seem like there was no delay. In this post, we’ll tell you about skeleton screens and how it can get rid of your slow-loading nightmares.

So, what are these spooky sounding skeleton screens?

A Screenshot of of a loading Facebook homescreen

Skeleton screens are the better alternative to progress bars or spinners. It’s a blank page that mimics the layout of an actual web page that it’s trying to load. The primary purpose is to imitate the page as to give the website visitor the feeling that the page is actually loading.

Fast Company stated a study by Google that reported they lose about 8 million searches a day from 4/10 of a second of delayed loading time. This is why a skeleton screen is so important. Mimicking a loaded screen will give your site the needed time to retain the attention of a visitor while the page loads.

Progressive loading is one of the recent developments in Skeleton interfaces. As the name suggests the Individual page elements become visible as they load progressively instead of displaying all at once when the page fully loads.

There’s a challenge though

The only time you’ll have a hard time designing skeleton screens is when you’re deciding the elements your site will have as placeholders. The most effective placeholders are UI elements, as website visitors are usually attracted towards the interactive elements when they’re looking for specific pages.

The benefits of getting it right

A screenshot of a loading LinkedIn homescreen

Skeleton screens can lower site/app’s bounce rate. When a website visitor sees it, their eyes will gravitate towards the feature they’re most likely to use. Take LinkedIn’s loading page for instance.

If a visitor needs their profile information, they will automatically look left for the loading element or group of elements that resembles a profile info structure. If they want to go through the updates from their network, then their eyes will go towards the center. Same goes for one of the early adopters of skeleton approach, Facebook.

Benefits we talked about at a glance

  • Lowers your bounce rate
  • Helps website visitors feel less frustrated with load times
  • Gives people a prediction of where certain content/images will load
  • Shows people that progress is being made in the loading process

Why Not the good ol’ spinner or progress bar?

A GIF of a loading spinner

When a visitor’s in a hurry to find information and you see a slower, stagnate loading bar or spinner, what do you think?

Most people think, “How many seconds will I give this site to load before I leave and look for another?” The visitor’s frustration will rise as they stare at this one loading bar and will be more likely to bounce.

Spinners/loading bars give people uncertainty about the load time and uncertainty will lead to them leaving a site. This is why skeleton screens are necessary for better UX.

Bonus tips

  • Break down your page bit by bit to outline it
  • Locate your static graphics that won’t change while the site is being used
  • Create the body of the site, using those static graphics first
  • Fill in where you know your text populates — it should look like a background, not like it’s appearing from nowhere
  • Test the skeleton screens as you implement them
  • Tweak images and imitated text boxes until they more closely represent what your page actually looks like

Even though Skeleton screens are just a cosmetic cure for slower loading applications but it does the job of retaining the visitor’s attention real well.

We hope that you enjoyed this post about skeleton screens. If you’re looking to improve your UX beyond skeleton screens, then this UX Training might be just the right thing for your team.