Coding Archives - LunarLincoln

Feb

Design for Fat Fingers

Have you ever had this happen when using your phone?

You typed in a ton of things on a page and then go to tap the submit button and your finger accidentally hits another button or link nearby? Or you weren’t able to type in the fields to begin with because you couldn’t get the cursor to move to them?

Screens these days are getting large and we can technically show a ton of things on there…but the thing is…our fingers are the same size they’ve always been (and not all of us have tiny hands like Donny T.).

A rookie issue when getting started with mobile design is making your touch areas too small or crowding too many things in one spot. (You can infinitely scroll, which means you have infinite space so chiilllllll and space that stuff out PLZ!)

Making things hard to tap makes users frustrated, and when they’re frustrated, they don’t return. BYE YOU GIANT HAND PEOPLE! I DIDN’T WANT YOU SHOPPING ON MY APP ANYWAYS. (That’s probably not what you were going for, but that’s what they think.)

So what SHOULD you be doing when designing buttons for mobile apps?

Luckily for you, you don’t have to go around measuring the finger tips of all of your potential users. Apple and Android have determined the optimal tap targets for you.

Apple’s Human Interface Guidelines recommend a minimum 44 x 44 px area while Android recommends 48 x 48 dp* when designing buttons for mobile apps.
(Let’s not go into the px vs dp discussion today but here is some reading)

Now that’s a good starting point but those are MINIMUM requirements. Actually the average human finger pad is 10–14mm and the average fingertip is 8–10mm, which mean you should be shooting for more like a 57px touch target. This is also backed up by tons of research. Check out Fitt’s Law if you want a deep dive.

That’s pretty big. Is my screen just going to be giant buttons?

Don’t worry! While it is good to have a decent button size not only for tapping but also for legibility/accessibility, you don’t always have to give that much visual weight. You just need that much spacing around your tap area so that there is no overlap with another actionable item.

Image courtesy of Material Design Documentation

When starting your mobile design make sure to set up sufficient padding around all of your buttons using the specs above for the tap areas.

Happy tapping!

Jan

A new look

Oh hi! You miiiight have noticed that things are looking a bit different at the online mooncabin. We decided that we were long overdue for a facelift, since we’ve been rocking the same look since 2014. The outside was workable but the inside was a bit of a time warp. Plus in the past few years we’ve been itching to add some new content but couldn’t figure out how to cleanly implement it with the old template.

The old template

Our old website was a wordpress template implemented before the invention of “page builders”. The inside was a scary land of stacked shortcodes. We didn’t like touching it because each time it required diving back into learning the mystery pseudo-code that stitched everything together. The template ceased being supported a few years ago but at that time we were mid-mobile-dev-mania and didn’t have time to look into alternatives.

What next?

So here we are: 2019. Web development has totally evolved, search engines are now super fancy/picky, responsiveness is key. Even WordPress, itself, decided to undergo a bit of a renovation this year. We’ve built a few other websites in the meantime and it’s helped me have a better idea of what we want and don’t want. We still recognize that we are better mobile devs than web devs, so we weren’t looking to build anything too custom. I’ve test driven several different page builders in the past: Avada’s Fusion Builder, WP Bakery’s Visual Composer, and this newcomer Tatsu run by Brand Exponents. I really dig the interface for Tatsu – it marries flexibility with simplicity and since it’s relatively new, it isn’t saddled with a ton of baggage/backwards compatibility like the industry leaders so we went ahead and dug in. Several iterations later – I think we have our final result.

What’s new?

EVERYTHING! Just kidding. Some stuff is really familiar, because its true and it works, but we did want to revisit how we talk about our work. We added a huge section on our Process. Building mobile apps is still a new concept to many people and “how does all this work” is the #1 question we get from leads. Dumping an entire load of process on someone in an initial meeting can be somewhat overwhelming, so it’s nice to have a place that potential clients can check out at their own leisure. We have a new area that focuses on our internal projects, which will grow in the new year as we add new ideas and ship more.

In the meantime, keep checking in. We’ll keep adding and polishing in the upcoming months, but I wanted to go ahead and kick off 2019 with some fresh code. Hope you like what we’ve built thus far.

As a side note: There’s really only one ongoing debate to settle – ARE THERE ENOUGH SPACE PUNS ON THE SITE? (Wiley always thinks there should be more.)

Aug

Sifting your User Research

So last we left you we were meeting with every meetup or conference organizer in the Metro-Nashville area. And then I emailed some in San Francisco for good measure.

When we’d meet, I had a giant list of questions that I’d generally attempt to cover during our chat. If we veered off into an uncharted area, no problem, but I typically tried to cover some of the same topics with each and every person I spoke with so that later I could compare and contrast responses. After each meeting, I’d “brain dump” everything we talked about into a text document. At the end of this I had over 20 pages of “notes” from organizers here in Nashville.

Welcome to Jennifer’s crash course in user research….

Did everyone say the same thing? Nope.
Did everyone have exactly the same issues? Nope.
Did you really expect every single person, to have the exact same needs? Well, no…but that would definitely have made this easier.

So how do I take all of this broad feedback and use it to come up with meaningful answers?

First I looked for trends…

What is something I heard from more than 3 or 4 people? Something that kept coming up without my asking or prompting?
What was the response when broadly outlining my idea? Tepid, interested? People will rarely, if ever, ACTUALLY tell you they don’t like your idea. They’ll just…kind of nod and make noncommittal statements about the idea instead of discussing how they, themselves would use it.

Now what are the trends amongst the people who offered similar suggestions or had similar responses?

Is it one specific kind of person or kind of meetup/conference?
Are issues noticeably split amongst different groups?
Are these suggestions/trends actionable, solveable, and from large enough demographics?

I discovered that those who, in a previous life, held a job that required them to be more social didn’t have as hard of a time going out there, hitting the pavement, and offering the right information to potential sponsors. I also noticed that organizers who had been doing this for a while succeeded through trial and error, or through helping with other local efforts like tech conferences where more experienced people gave advice.

All of a sudden our market for organizers who needed help with how to ask for sponsorship was smaller. It was looking like just newbies and those whose core competency was more solely focused on code versus people .

But, I DID have one piece of feedback that came up over and over from this more experienced group – “Once we’ve used up our personal connections, we don’t know who specifically to ask to grow our sponsorship” …not what to ask, or how to ask but WHO.

This was different from our initial assumption. (And why you do this process to begin with). And this isn’t feedback that we can easily solve with a simple solution. Which makes sense—usually the hardest problems are the most prickly. After some internal discussion we did determine that there were a few potential ways to tackle the “who to talk to” problem but none of them are super easy.

So now what?

We have to ask ourselves, can our potential product not only provide help to those with the “how to ask” problem (early stage meetup organizers), but begin to seed data and insights for those organizer-pros who have trouble with the “who to ask” part (veteran meetup organizers and larger conferences). Will our actual “value” be on the back end of the product and not where we initially thought?

In assessing your own user research ask yourself:

Are there still problems I can solve?
Can we still reach users with these pain points?
Is this still profitable? (Are there enough users with this pain point, is the solution reasonable to build, and will those users pay for it?)

For us, it’s time to go back to the business model and adjust our numbers. If not as many people are within our initial demo or willing to pay for the proposal product, can we get enough users in there to build data for a sponsorship leads product which seems more valuable to experienced organizers?

Next steps? We’ll attempt to broadly scope and estimate features for supporting the two types of users in order the reach profitability instead of just one. We’ll need to talk with organizers again now that we have firmer features in mind. And we should put some infrastructure out there to test the interest beyond Nashville (Product Hunt, Beta List, etc).

Aug

Testing the Waters – A New Product Idea

So you know how we were trying to “magic” an amazing idea last month? We made lists. We read books. We drew on the white board a lot. We looked at everything from Product Hunt, Beta List, and YCombinator. I even scrolled way back in the @BoredElonMusk Twitter handle (There are some great product ideas in there…that we’re not interested in building).

Well after weeks of being super negative about everything and thinking that we were never going to find anything good, we went on vacation to NYC. Then I went on a walk to lunch – gotta get my Turnip Truck Hot Bar fix – and I had an idea….

We host Nashville Cocoaheads. They have their meetings at our office. Sometimes we buy pizza or beer for them. One of their challenges has been finding sponsors. Mostly because they’re busy with their day jobs, not to mention sourcing the actual speaker part of the events. And this isn’t the only group. We’ve also had emails from friends who needed money for chairs for their usergroup. Like, a lot of chairs. Their event is super successful, hundreds of attendees successful, but we still ended up sitting on the floor one time. (We did give money for chairs the time we were asked and now they have amazing venue sponsors who have their own chairs).

This sucks.

My friends are trying to create wonderful things for their peers and shouldn’t be worrying about these small things. We’re sitting on the floor. Or drinking water instead of beer. Or rushing from the meetup to dinner because the organizer only bought 2 pizzas instead of 6 because they were paying for it out of pocket and now it’s 8pm and I’m super hongry.

Now I know the point of usergroups is not pizza…or chairs. But these things help. You’re tired at the end of the day, and you’re taking that little bit of energy left to go to a thing and learn something new. It would be nice if there was sustenance there, or even better…free tickets to a conference or a free pass to a new software tool. Congratulations on doing something extra – here’s another piece of help.

So, I got to thinking…wouldn’t it be awesome if there was a tool to help my friends find sponsors for their usergroups quickly and easily? They wouldn’t have to cold email. They wouldn’t have to figure out how to make a pdf with their sponsorship packages when what they care about most is being a really good software developer. They wouldn’t have to buy the pizza themselves or email their friends for help (even though we like to help).

But wait….

is this a real problem? Or are my friends just bad at organizing meetups?

So I sent quick emails to friends who are organizers along the lines of “What do you think about a sponsorship tool for usergroups…” I got responses back that were practically epistolary novels about how YES. YES WE WANT THIS. OH GOD. YES. and then 1,000 ideas of what it could look like.

Well then….let’s proceed.

So I wrote some more emails… a ton of emails actually. And I had coffee, and beers, and Slack convos. And… it seems like a problem a lot of organizers have. Maybe not always on the same dire level but it’s still a task no one likes but everyone needs.

Sidebar: I LOVE OUR LOCAL TECH SCENE and how amazingly patient and helpful all of the Nashville organizers and sponsors are. You guys make me want to build this thing immediately, if only to give back to those who have already given Nashville so much.

Currently, I’m still in the process of having meetings with the Sponsor side of the equation but I’m looking forward to it.

I think we might have found a winner you guys. We’re passionate about our local tech community (and other ones like it), this is something within our grasp to build (sorry, massive email sentiment analysis idea), and maybe just maybe it can be profitable (sponsorship help for podcasts, for school clubs, for little league teams, for any grassroots organizer of anything).

Next up. More meetings. Competitive Research. TAM and monetization. What does this idea look like in feature form? We’ll keep you posted.

Apr

Let it go – Building a real MVP

In Startupland, the most valuable product is the Minimum Viable Product (MVP). Why? Because you didn’t blow your entire budget/savings getting there.

People often come in and start throwing this term around “MVP”. Requesting something along the lines of: iOS and Android apps, a web portal, and a full dashboard for all users and grandma! Oh and an admin portal with state of the art features as well.

This is not an MVP. This is your wish list. Your nice to have list. Your 2 years in list.

“But…but… I NEED to have these things or I won’t be successful.” you say.

Hogwash. Success is based on building the RIGHT thing. Not ALL the things. I know it’s exciting to start building but slow your roll!

While it’s not too hard to trim an initial feature list down by pairing some low hanging fruit, oftentimes you’re still not at your target budget. You may need to drastically slash costs to get to market or not get there at all. At this point we’re not talking about removing 2 questions from the signup page or changing out how fancy search is, we’re talking about removing entire areas or better yet – entire platforms.

Prove your business model before investing in it in multiple tech stacks.

Do you rrrrreally need that admin portal for your 25 users? Can you hold off on Android to see if what you have in iOS is really what users want? Do users really need to have both web and mobile access?

What should I cut when I don’t want to let go?

1. Assess features & users to find platform launch targets

Where are your users hanging out? Are they older? Younger? Are they turning to the web for this service? Is this something they need on the go? Assess your audience and the core features of your product to determine whether this is a web or mobile play to start (you can add more entry points later! This isn’t forever!)

2. Sweat Equity for Behind the Scenes

Even the great and powerful OZ understood the value of manual effort.

Do you really need all the management stuff automated? Weigh your time versus your cost of development. Is hiring a $10 an hour intern to review applicant profiles cheaper than building a machine learning service? Can you keep track and manage payments with excel and quickbooks instead of a custom point of sale system? Only upgrade/build your tools when the workload demands it not before.

3. Tech debt can be your friend (in the beginning)

Don’t polish and deeply invest in a feature if it isn’t proven yet. High traffic areas can be improved upon once their value is clear. What if you spend half your budget on a feature that when launched collects cobwebs from your so-called target audience? Make pivoting painless with lightweight development decisions.

Infinite runway? A budget as deep as the Grand Canyon? You may not have the make these hard choices, but I would still advise you to do so. It’s healthier for a product to be able to grow based on real world user experience. Give yourself the flexibility to change features and change messaging without having to visit 6 different codebases and remove 8 months of work. A simple product launch isn’t easy or straightforward, but it’s a smart one to start with.

Still having a hard time slimming your MVP? We’re here to help! We love creating products that built for success and don’t have a problem saying no (or strongly judging you for not being able to say no to yourself).

Need someone to question all your decisions and make helpful suggestions?

Jan

Is Your App Idea Special?

Let’s be honest – app ideas are hard. The world is big and fast-moving and what’s hip today might flop tomorrow. Having what feels like a good app idea is only the first small step in building a successful product.

The Process

So, imagine you’ve dreamt up a great new app idea, what should you do? The very first thing any entrepreneur should do is check if their idea already exists, but not for the reasons you might think.

You’re not looking to see whether the door is shut in your face, you’re looking to see if the idea has potential in the market. Most app ideas are not purely original. Tons of people are having the same great idea each and every day. But that’s okay! Other people with similar ideas prove that it is a good one! Seeing competitors shows that there is a need and it is feasible concept.

Realistically, you ARE going to find a few apps that do some similar behavior to what you’re imagining. Whether those apps are wildly successful or quietly unnoticed, you’ll have to innovate and find ways to improve upon these existing products. Think about features that are missing, designs that can be improved, and new ways to monetize. Do you think this market has room for another app? How can you attract the most attention?

What if you go app hunting and can’t find anything even close to your app idea? In this scenario, your app idea typically falls into one of three cases:

Your app idea is original and nobody else has thought of it
Your app idea has been discovered to be too costly to develop
Your app idea isn’t appealing to enough users

Naturally, you want to be in the first category, but what if you’re not? This is hard, and you’ll likely need to reach out to potential users and gauge their interest. Continuing down this path is certainly risky but can still be very successful.

The Bottom Line

The harsh reality is that most app ideas are uphill climbs. You’ll work, you’ll iterate, you’ll advertise, and sometimes you’ll fail. Failure is a tough pill to swallow, but it’s a fantastic learning opportunity. Did you make a mistake when assessing the viability of your idea? Did market conditions change? Or did someone else beat you to the market while you were developing? No matter the outcome, use this experience to craft your next great app idea.

Oct

A Brand New Android Studio – 3.0!

There are few events in life that give developers such bliss and excitement as when their favorite tools receive a healthy refresher. Earlier this week the kind and hard-working folks over at Google released the official version of their long-awaited upgrade to Android Studio. It wasn’t an unusually long wait (Google seems to release new major versions roughly every 6 months), but the anticipation of diving into its new features has kept me watching Android Studio’s Stable Channel for months.

In the events leading up to Google I/O in May, the Android Studio team had teased the community with some incredible new features for Android Studio 2.4. Many developers, myself included, had our collective fingers crossed for a surprise release at the event and were shocked when Google announced official support for Kotlin in Android development. Additionally, they boldly nixed the 2.4 version of Android Studio from existence, bumped to a clean version 3.0, and continued pushing out numerous betas and release candidates. Now, many moons later, we’re blessed with a well-tested and feature-packed development environment ready for production use.

Without any further ado, let’s talk about some of those new features.

Kotlin

A few years ago, Kotlin burst onto the Android scene and was met with both praise and skepticism. JVM languages like Kotlin aren’t uncommon and most aren’t well suited for Android development (with the notable exception of Groovy, which Gradle uses). However, continued Kotlin development attracted more and more followers. Plugins were made for Android Studio and soon Kotlin became a common concept for cutting edge developers. Google must have been keeping its eye on Kotlin as well, and for the first time in Android’s history, Google announced full first-party support for another programming language to sit alongside Java (ignoring the NDK, since Google most certainly does!). Kotlin’s concise syntax shares similarity with numerous other languages, notable Swift, Apple’s preferred iOS and Mac OS development language. It addresses numerous Java shortcomings such as null safety, a lack of class extension functions, and easy threading support via coroutines. The full list of Kotlin features is long and you can read about them here!

Java

On the topic of languages, Java got some love this time around as well. For a multitude of reasons, Android’s Java doesn’t always have the same functionality as the base language. One of the most common criticisms of Java is its verbosity, especially with anonymous classes. You know, the ones you make to implement callback interfaces like View.OnClickListener. Java introduced support for lambda expressions, which are essentially abbreviated functions to reduce repetitive boilerplate code, in Java 8. However, Android struggled to provide support for lambda expressions; you had to use the experimental (okay, buggy) Jack toolchain or the 3rd party Retrolambda library. Finally, Android developers can use natively-supported lambda expressions. This is a huge plus for libraries like RxJava which rely on numerous single-method interfaces, making them prime candidates for lambda expressions and drastically reducing code length.

Android Studio

The last new piece I’ll talk about is an upgrade to Android Studio itself. For as long as I can remember, I’ve been using the Android Device Monitor to profile the performance of my apps. It was a little ugly and a little hard to use, but it got the job done. Google used its magic and transformed it into the Android Profiler. Earning a proud place next to the Build and Stop buttons, the Android Profiler button opens CPU, memory, and network monitors right within the Android Studio window and sits nicely next to Logcat and your other bottom toolbar menus. You can monitor performance, view payload information, find laggy parts of your apps, admire the very pretty interface this amazing suite sits within, and more. I’m eagerly looking forward to testing my apps and improving my code using these upgraded profiling tools.

I could go on but instead you should go download the new version of Android Studio yourself and play around!

Aug

Adventures in ARKit

Recently, at WWDC, Apple announced their venture into the world of augmented reality. If you’re wondering what exactly augmented reality, or “AR” is, it’s similar to virtual reality but instead of creating a completely virtual world for a user to experience, AR takes the real world, as captured by your camera, and places virtual elements into it – a la Snapchat face filters or Pokemon GO.

Apple supports AR in their latest phones with a new framework known as ARKit. This framework will allow developers to create some intriguing experiences through either SceneKit (which uses 3D models), SpriteKit (which uses 2D sprites), or Metal (which allows for custom rendering).

Building our first ARKit app

We at LunarLincoln thought this would be a great opportunity to explore the possibilities of AR. However, before we could do that we had to have the right tools which meant we had to upgrade to the new Xcode 9 beta and have a device running iOS 11 with at least an A9 chip which comes in the iPhone 6S and up.

Once we knew we wanted to do something with ARKit we needed to brainstorm some ideas. What would be a cool thing to throw into the real world, and what are the limitations of the software? A lot of time was spent scrolling through MadeWithARKit to see how people were using it.

The primary application of ARKit early on was creating interesting experiences such as showing a virtual rocket land on your pool, or a robot dancing in your living room. The other side of it came in the form of practical tools such as a virtual tape measure, or being able to place furniture in a room to see if it would look good or fit.

To get a feel for ARKit, our app originally started as an app where you could tap on the ground and a 3D model of some sort would appear. This was a nice idea and gave us a feel for the logic and programming behind ARKit, but it was boring.

The idea was presented to make an item rain from the sky. What if we applied the same logic where we tapped on the screen and something appeared, but instead of some boring 3D model, it was a rain cloud that showered money? Yaaaaaas.

The Make it Rain concept

We would use SceneKit and ARKit together to create a cloud wherever, and then let it rain money that would then pile up on the ground.

To get this app working the way we wanted we had to read quite a bit about one of the staples of ARKit: plane detection. ARKit uses feature points and plane anchors to find surfaces and mark them in 3D space. Once ARKit has gotten us this information, we can use that position to simulate the ground by placing a physics body there so that as the objects are falling from the cloud they will smack into the ground and stop. SceneKit physics controlled the falling and bouncing once objects hit the ground in addition to making a body dynamic with the appropriate category and collisionBitMasks filled out.

Looking at this app now, most of the learning and code came from SceneKit. ARKit, itself, was fairly easy to use. The worldtracking that fixes an object in space as you move around it is just one line of code (!!!). So ARKit gave us the ability to place objects into the world and realistic positions, but the bulk of the development behind this went into giving objects physics, making sure they collided, and that they were in the right position.

Final result?

So what’s the catch?

Working with ARKit presented several new hurdles to deal with. Debugging and testing with this app definitely felt strange. You frequently had to look up at the ceiling or back up and walk in a giant circle just to find where in space you have placed your 3D model. Getting sizes and perspectives correct was a challenge. A model might appear way up in the sky because at it current scale because it is the size of a cruise ship, but looking at it from your current perspective it looks to be the size of a car.

Another issue to wrap your head around is that the camera is the origin. If you decide to place something in space using fixed coordinates it will be relative to where you are holding your camera. Make it Rain had an invisible plane one meter down from the camera to catch anything that fell off of the edge of the floor plane and remove it from the scene. When I was testing the app sitting down, the raining objects were hitting the ground and piling up, but when I stood up, the invisible plane would rise above the floor’s plane and make the objects disappear before they touched the ground. This was a weird one that definitely tripped us up.

Beyond weird 3D space issues, there was the issue of finding good 3D models to use in the project. Finding free models that are in a format compatible with SceneKit, available for personal use, and that don’t look like crap is pretty difficult. SceneKit relies on Collada or .Dae files which aren’t particularly common. There were a few good sites out in the interwebs but Turbosquid was probably the best for finding models. That said, many ARKit developers dip into Unity for their models.

All in all this was an exciting project to work on and put out there. It is always enjoyable to explore new software. Especially one that lends itself to creating interesting experiences such as ARKit does. The current version not only rains money, but now has the exciting additions of sharks and stars.

We have a bit more polishing to do before public release alongside iOS 11 this fall, but we’ll be sure to make it available to everyone then. For now you can learn more about coding with ARKit here or here.

Jun

4H Pedometer Party

We recently partnered with the 4H Grow program and it’s coordinator, Andy Lantz to show their summer campers how mobile development works. Andy informed us that the kids had been wearing pedometers everyday for the past week and were recording their steps in their notebooks. Our mission was to figure out a way to take this data, and use it for a mobile project that would be interactive, educational, and fun.

First we had to come up with an app concept for the pedometer data. The idea was presented that we could take all of the steps of an individual with their height and calculate how long it would take for somebody to travel to travel to various places. Now, where would it be interesting to walk to?… Why not the Moon or Disneyworld?

We have the idea. What comes next?

Prior to building code we needed a plan and all plans start with drawings (also known as wireframes in the mobile app business). They were just some rough sketches outlining where all the labels would be, what they would say, where buttons would take you, etc, but they got the job done.

After some review and finishing touches the pencil and paper prototypes were handed off to Jennifer, our UI designer, to be given style and design that can serve as a road map for building the app in Xcode. For this project we decided to use stock elements that resulted in simple code. This would help get the app done in a short timeline and make it easier to explain.

The final UI looked something like this:

After looks, then comes code

We then built the UI in Xcode storyboards. While the surface looked good and matched the designs, there wasn’t any logic hooked up to it yet.

The next task was to think about the math behind the app. We needed to take average steps for the week alongside a user’s height and turn that into a distance traveled per day. We would then take that distance traveled per day and apply it to the various locations we had selected.

To get the distance a student would be traveling each step we did some quick Googling and came up with the number .414. This number is the fraction of your height that roughly equates to the length of your stride.

App Looks, App Calculates, App is Tidied for Play

Once the UI and math had melded together to achieve the desired result, it came time to think more about the code demo. We needed to review and look at the code in an approachable manner. Using a Swift Playground as a teaching tool seemed like an excellent solution. By putting some of the logic into a Swift Playground it would be much easier to show the students what exactly happening to their steps from when they first enter them into the app to when they get displayed at the end.

A playground is also great for sharing code with the students. All they need is an iPad and to download the Swift Playgrounds app. We created a google doc setup with the source code for the playground that anyone can copy and paste into the app to manipulate or play with.

On a sidenote: Swift Playgrounds are great resources for testing out code ideas and learning code in a simple manner. Check out these other Swift Playground projects here.

Demo Day

After the app and Playground were complete and ready to go it was time for the students to come to the office, learn about LunarLincoln, test out the app, and see how long it would take them to walk to the Moon.

After the students had gotten their data for the Moon we listed them out on the whiteboard and compared results looking for any interesting insights. Would shorter students take longer? What about students who walked more than others? In general we discovered that walking times averaged around 400 years for the campers!

Interesting Discoveries in QA

The app for the most part worked out great, all of the students were able to get their desired results, but afterwards they wanted to experiment with some fictional data. They began to either put in one step a day which resulted in it taking an astronomically long time to get to the Moon (pun intended) and the result field would overflow, or they would put in nines until their fingers got tired or the app crashed and again the result field would have issues. It was usually the latter.

Problems with this “creative” QA experience? The app had issues with integer overflows because we had assumed they wouldn’t walk more than 2,147,483,647 steps a day and thus: crashing. A great learning experience for both our intern, Logan, who built the app as well as the kids for their creative experiments.

Recap and Materials

The experience was challenging for our project lead – Intern Logan, and was educational and fun for the students. They were able to see what some of their favorite apps might look like under the hood, and see what goes into building a mobile app from the ground up. To go through the full presentation and playground: visit Lunarlincoln.com/4H

Jan

Native vs Hybrid Apps – Part II

We recapped the technical decisions of whether you should build natively or with a hybrid solution back in this post. But let’s be honest, native is “technically” always best. The real reason client’s opt for hybrid solutions comes down to one thing. Money.

Why pay for development twice when you can build it once? Right? riiiiiight?

Well, sometimes.

If your desired app is largely simple elements and displays content: like reader apps or lists or shopping or blogs then YES HYBRID! If your app only needs maybe one or two things that need native integration then PROBABLY HYBRID.

The catch with hybrid is that any part of the app that needs any sort of custom UI or native phone integration like maps or camera, etc is going to need to have a native-code bridge written between your hybrid solution and the source. Which means we’re back at native development twice (Android and iOS), and your money savings is starting dwindle. Remember this image? Also, that in-house .NET team you thought could whip this up in their free time? They might get a bit stuck at those parts.

When there are new updates to the operating system from Apple or Android these third-party providers need to write their own hybrid platform features to interact properly – causing you to be reliant on their timeline for upgrades instead of implementing code updates the day the OS is made public.

To recap the recap:

Hybrid is cheaper in that it often uses web developers (lower rate) and is mostly build once, use twice. Great for simple projects, first/test versions, or apps that generally are reproducing web content verbatim.

The caveats are that:

You’ll still need to build native bridges to more complex parts of the app (bye web developers!)
You are reliant on updates by your third party platform to maintain pace with new operating system updates (dependencies)
It still has those technical limitations of UI and responsivity (design award bummers)

I’m sure you’ll find lots of articles about both – we’re obviously a bit biased being an all native shop (…for now. Why hello React Native).

But sometimes, after listening to a clients needs, features, and budget, we still find ourselves recommending hybrid. Honestly! We want you to get the best value AND the best app! Success for everyone!

So take what we’ve said above and before and assess for yourself! Do some pro/con lists. Ask your mom. (Or don’t ask your mom but DO ask the opinions from many potential contractors). Read more than one article.

We hope at the end you come back and choose to build your app-baby with us (if its native 😉 )

12 3 4