LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Working to live at LunarLincoln
Apr
25

Working to Live not Living to Work

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business, Coding

“Startup Life” – everyone knows this means long hours and intense work schedules right? It’s all about doing more with less, and if you’re not putting in more time than everyone else you’re clearly not cut out for startups right? Right?

Working to live at LunarLincoln

A little known fact: LunarLincoln has a 35 hour work week.

We also let our crewmates work whatever hours they want to. Why? For so many reasons. Because we want to create a sustainable work environment for our crew. Because we know we get better quality work when our dev’s are fresh and in the proper mindset for the task at hand. Because sometimes you hit a wall and just need to take a break to clear your head. We don’t put in “Let’s check Reddit since I have 30 more minutes till 5pm” time, and we don’t put in “I’ve already worked 50 hours this week on this project but have to put in 10 more to push it across the finish line, who cares about code quality at this point. Get. It. Done.” time.

http://alifeofproductivity.com/number-of-hours-work-a-week-to-be-the-most-productive-35/

Graph courtesy of http://alifeofproductivity.com

We only require 32 hours because our crewmates are individuals who deserve to be husbanded and treasured. They aren’t expendable and they’re not interchangable. We aren’t a code factory, we’re a small shop of craftsmen. (Plus there is some science to this madness ^)

Do your work. Do it exceptionally well and be proud of what you’ve created. Then go home and enjoy your life. If that life is learning more about mobile app development or building your own apps, awesome. If it is going to concerts and throwing dinner parties, that’s awesome too. We want our team to take that time and recharge and refresh, and most importantly we want them to live their lives.

But wait, you said a 35 hour work week, what are those 3 extra hours?

We want 32 hours of client-billable work. The work that supplies the paycheck. But you know what not only helps our crew but the final client product too? The time to learn new things. Learn the best new techniques, programs, and languages so that we can be more efficient, effective, and on top of our game. Those three hours are for personal development, whether that is reading blogs, using some extra time to try a new thing, or going to an event in town. It’s important and nonnegotiable.

While there are many approaches tech companies take for “salaried” workers we feel that this equation works the best. “Startup Life” doesn’t have to equal epic burn out.

200a

For us, “working to live” makes for a happy balance and keeps us excited to build new things each and every day.


Native versus Hybrid efficiency graph
Apr
06

Native vs Web Apps

  • Posted By : Patrick Goley/
  • 0 comments /
  • Under : App Advice, Coding

When building a software product for mobile, there comes a time early on when you must decide between building a native application or a responsive web app. When making such a decision, it’s very important to understand the implications of going one way or the other. A native app is typically more expensive to build, but the extended capabilities and high speed execution often makes it necessary or at least advantageous for certain products. Today we’ll explore a few benefits of building native apps to help make this decision easier for anyone setting out to build a new mobile product.

blog-42

Why go native?

Direct Hardware Access

Icons8One huge advantages of natively built applications is they have direct access to many hardware features that web apps simply do not. While HTML5 has brought easy access to the camera and microphone with the <input> tag, these elements simply output a file and don’t give you access to the media in real-time. If you want to build fun camera filters or do any kind of signal processing, you’re much better off in the native realm.

While web apps have some access to media capturing hardware, they don’t have any access to some of the other sensors on the device. For example, native apps on iOS have full access to all HealthKit data (should you allow them) collected by the motion co-processor and other activity trackers, which are always working whether your app is running or not. Native apps can also use geofences and other location-based triggers to provide context-aware behavior and offline notifications, which can draw your user’s attention back to your app at opportunistic moments.

Blazing Fast Execution

200 (4)Native apps can work more efficiently because they run directly on the hardware, meaning there’s very little overhead to performing computation. This can make a huge difference when doing lots of graphical work or anything that is computationally expensive. While hardware-targeting makes applications less portable, it allows them to really take advantage of the processors they run on, giving you the high resolution and fluid graphics you see in native games and media apps today. Apple’s graphics library Metal is a great example of this, being designed specifically for the GPUs in Apple’s products to achieve maximum performance.

User Experience

There’s usually a clear difference in appearance and quality between native and web-based apps, as web apps lack the responsiveness and familiar UI elements of a native app. While web apps can certainly accomplish a lot, the extra layer of separation brought by running in a browser or web view rather than natively means the app can’t respond as quickly to things like touch events. This accounts for the slight lag you experience when interacting with the UI of web-based mobile apps, which amounts to a less-than-stellar user experience. Also, users may not pick up on custom UI controls from the web when they are used to a consistent experience from native apps on their platform, which can lead to usability problems. If the user feels like they’re swimming upstream to use your app, they probably won’t keep at it for long.

Offline Functionality200 (1)

One clear limitation of web apps is the necessity to download them over the internet each time they are loaded. Since native apps are installed once and can store tons information on the device, they can provide all kinds of functionality without an internet connection. iOS apps can even preemptively load data before the user opens the app through silent push notifications that “wake up” the app to retrieve new data.

Even with an internet connection, the first few seconds of a web app experience often consist of spinners and sluggish stylesheets causing elements on the page to jump around as it loads. This requires a measure of patience from your user, which might be too much to ask from some users especially after navigating through a few pages. With user attention spans getting shorter and shorter, you need to capitalize on every second they spend in your app, creating value for them and not putting them on hold to download and render bloated web pages.

"We're getting really close to ready" – the false dream of hybrid apps pic.twitter.com/xyvXT3qNao

— Bill Morein (@wmorein) May 5, 2015

In short, while native certainly isn’t the right choice for everyone, there are a quite a few cases where it’s necessary or at least beneficial. It’s important to consider these implications not only for the current state of your product but also for it’s future, as it would be unfortunate to commit to a web-based platform only to have to rebuild later when you need native-only features. While historically writing native apps have meant coding for one platform at a time, there have been big developments in native, cross-platform solutions such as Xamarin, now backed by Microsoft, and React Native, brought to you by Facebook. These solutions, while still growing, hope to deliver the fully native experience without limiting you to a single platform which can greatly reduce the cost of certain projects.


Mobile Madness Championship
Apr
01

Mobile Madness – The Championship

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Coding

This is it, you guys. THE CHAMPIONSHIP. Who will be the ultimate winner of Mobile Madness 2016?!?

200

Swift vs Jake Wharton

[separator type=”” size=”” icon=”star”]


Swift

Swift has had a crazy, semantically satisfying ride to the finals in this tournament. It was picked in Round 1 over the world’s most used programming language, Java (*ahem* thanks fanboys *ahem*). In Round 2 it beat out it’s arch nemesis, the big, bad Objective-C. And then in a crazy match up that left even Apple fanboys wondering who would win, it stomped iOS. Finally, Swift beat out the juggernaut that is AWS to earn a spot in the finals!

We’ve covered Swift’s benefits and shortcomings fairly thoroughly in previous posts. To recap for you fair-weather fans:

“Swift is quite new on the scene, which only hit 1.0 in September, 2014. It has been acclaimed for it’s use of functional programming and value types which can help simplify problems in the minds of developers. With much to prove for general use outside of iOS and Mac apps, it’s support from the open source community as well as big players like IBM is driving adoption for the language at a rapid pace.”



Swift2

[separator type=”” size=”” icon=”star”]


jake

Jake Wharton

Aaaand on the other side we have the legendary Jake Wharton. In Round 1 Jake scored a win over UX giant Roman Nurik. Then he won the battle of the Jakes to advance over iOS indie Jake Marsh. He faced off with Swift contributer Erica Sadun and came out victorious to advance to the final 4. And somehow he beat out Steve Ballmer (!!!) to advance to the finals.

We’ve written a lot about Jake in our pervious posts, but for those not paying attention here’s a recap:

“Jake thrust himself into the spotlight with his incredibly famous open source Android libraries such as ActionBarSherlock and NineOldAndroids, as well as his contributions to Square’s massive catalogue of open source libraries such as Butterknife and Retrofit. He continues to deliver enlightening talks and presentations about Android and its continued evolution as a platform. ”


[separator type=”” size=”” icon=”star”]

Who will be the winner?!?

In a lot of ways, this matchup comes down to iOS fanboys vs Android fanboys. After all, those of us who grew up in the early days of Android development would have had a tough time without Jake’s timely and useful libraries. On the other hand, Swift has breathed some new life into iOS development and actually got us excited about a programming languages. So who will you pick to be the one to rule them all?

appleandroid

Vote in our final Twitter poll here!


Recent Posts
  • Copious Communication
  • Initial Questions for a New Mobile App Project
  • Gif TV: A LunarLincoln Product
  • Onboarding other peoples code
  • What’s in a name?
  • Don’t build it all. Picking a Platform.
  • Talk to your Users
  • Design for Fat Fingers
  • A new look
  • Hourglass for Jira
Archives
  • May 2021
  • September 2020
  • November 2019
  • October 2019
  • June 2019
  • April 2019
  • February 2019
  • January 2019
  • October 2018
  • August 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
  • August 2017
  • June 2017
  • February 2017
  • January 2017
  • September 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • October 2015
  • September 2015
  • July 2015
  • May 2015
  • February 2015
  • December 2014
  • November 2014
  • September 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • December 2010
Categories
  • Agency
  • App Advice
  • Branding
  • Business
  • Business
  • CaseCollage
  • Coding
  • Design
  • Design
  • NSVille
  • Uncategorized
  • Web Design
Copyright LunarLincoln 2023. All Rights Reserved