I'm switching from a Nexus 5 to an iPhone 6 Plus, and this is my story

And it feels like a lot of folks are doing the same thing these days. I'm not sure what's the main reason driving everyone else, but here are my thoughts about why I'm doing it.

Let's get something out of the way first: I love Android. I've owned 3 iPhones (3GS, 4S, and 5) and 4 Android phones (Nexus One, Galaxy Nexus, HTC One GPE, and Nexus 5), so I kind of like both worlds.

How did I get here

With a Nexus 5 in my hands, I've been waiting very excited for the upcoming Nexus 6 (or Nexus X, or whatever) for a long time, but at this point is all rumors and nobody appears to have a definitive list of specifications. Heck, it's not even a fact that there's going to be another Nexus at all. And unfortunately for me, that's my only option for Android; it's either Nexus (stock Android experience) or nothing. I hate every single skin and bloatware that OEMs and carriers throw on top of the operating system, so there's no way I can be happy with something different.

That pretty much reduces my choices to those mighty Nexus devices that Google likes to sell every year, but with the entire Nexus program going away, I'm not holding my breath for the future.

(Rumors are that a program called "Android Silver" will take Nexus' place, but apparently this program is a new name for the existing Google Play Edition devices, which has its own problems that I don't like.)

So with all this time on my hands while waiting to read something concrete about the new Nexus, I started to speculate about the soon-to-be replacement for my current phone. And honestly, I couldn't convince myself that it was going to be better than the just-released iPhone 6 Plus.

Here you have in order of preference the reasons I'm switching and my predictions and thoughts about the upcoming Nexus device.

Is there going to be a Nexus 6 at all?

Nobody outside Google knows for sure, and it will be a bummer to wait all this time just to find myself in Christmas still with a broken (yes, my screen's cracked) Nexus 5.

The bad news here is that there's no specific day when you are going to realize "Oh no! There's no Nexus 6!". You can be very well waiting forever. Either a Google executive goes on record to say there's no Nexus, or the waiting period will be very very long.

However, despite of not being sure, I'm confident a new Google phone is coming alongside the Android L release later this year. I'd guess there's 90% chance of this happening. It's just that I'm very afraid of the other 10%.

Screen size

I like big screens.

30 seconds after trying the LG G3 5.5" display I was in love (but LG's skin pushes me away.) The iPhone 6 Plus has an amazing 5.5" screen as well, with a 1080x1920 resolution and a density of 401ppi. Certainly not quite as stunning as the 1440x2560 resolution with 534ppi of the LG G3, but I'm not convinced that my eyes will see the difference anyway.

Rumors are that the Nexus 6 will feature either a 5.2" or a 5.9" display. Some people say it will be Quad HD (like the G3), some say it will be HD (like the iPhone 6 Plus). Let's see what these options mean for me:

  • 5.2": My preferred option. I'd rather do 5.5", but never 5.9", so 5.2" is the best compromise.
  • 5.9": Too big for my taste. It would have to be super slim and barely have any bezel for this to be a manageable phone.
  • HD resolution: Definitively my choice if we are talking about the 5.2" display. Quad HD is too power hungry for such a small phone.
  • Quad HD resolution: Only if it's the 5.9" display, although I still have my doubts.

So putting 2 and 2 together, you'd see that even if the Nexus 6 has a 5.2" HD display I would be compromising comparing to the iPhone's 5.5". Any other combination and I'd be unhappy.

Battery

The new iPhone's battery life is the best I've heard of. Of course, with such a big enclosure Apple managed to pack a lot more juice into the device, resulting in a phone that lasts for two full days of normal usage for most tech-avid reviewers. I'm a phone junkie, and I'm ready to take all the battery life I can get.

What to expect for the Nexus 6? Well, right now the best battery out there that I've heard of is the LG G3's 3000 mAh. Reviewers say that the G3's battery life is not as great as the iPhone's (the Quad HD display is not helping here), so we can easily form a picture for the Nexus 6:

  • 5.2" + HD + 3000 mAh: This is the best combination and one that probably would be competitive to the iPhone's battery life. The phone will have to have a bigger enclosure (more noticeable bezels) to pack such a big battery, but I think it's a good trade off.
  • 5.2" + Quad HD + 3000 mAh: I don't think battery life in this combination would be competitive with the iPhone, although it would be better than the G3 for sure.
  • 5.5" + HD + 3000 mAh: Not as good as the first option, but still better than the G3.
  • 5.5" + Quad HD + 3000 mAh: Here you get what the LG G3 is offering today. Good, but not quite as good.

5.2" HD is again my winner, although this is assuming that we are going to be seeing a 3000 mAh battery. Anything less than that, and people will have to spend another year suffering with their phones dying at 5pm (like I am right now). I honestly think there's a 20% chance that the Nexus 6 will feature a 3000 mAh battery, and 80% that it will be something less powerful, like 2700 mAh, so my options aren't looking good here either.

Cellular Network

Yeah, this seems stupid but I like Verizon for their LTE coverage. I'm on T-Mobile right now, and although their LTE is faster, the coverage is not even close to Verizon's.

This hasn't been a huge problem for me, but I've noticed it enough times that I'd rather go with Verizon. I know I'll pay more, but I made peace with that already.

The Nexus 6 will never work with Verizon (Verizon's fault probably). It will be T-Mobile and AT&T only as always, so this would be another point were I'd be compromising.

Camera

If it's not the best, I'm pretty sure the iPhone 6 Plus has one of the Top 2 cameras in a cell phone out there. I can't name one phone right now that triumphs Apple's in this category (and doesn't suck in another 100 ways.) Love it or hate it, the iPhone is a camera that makes phone calls, and not the other way around.

The Nexus line has been famous for mediocre cameras. Rumors say that the new one might have a 13MP shooter (which will be a jump from the current 8MP on the Nexus 5), but we'll have to wait for the software accompanying that to draw any conclusions. That being said, I really think there's 0% chance that the camera will best the iPhone's.

Fingerprint scanner

The iPhone has one. I want one. It's convenient and powerful (I'm salivating here thinking about authenticating in apps using it instead of typing passwords.) It's been out for a year and people love it.

The Nexus? I'd give it 5% chance of the new phone featuring one, but even if it does, we'd have to wait for the software to catch up with Apple's. Hopefully I'm wrong, but I'd cross this one from your list.

Apple Pay

This is the final big reason I'm jumping the ship. Nobody has tested this yet outside Apple (it's going to hit the public next month) but Apple made it look extremely appealing during their presentation.

And of course they did, but I trust them. You know Apple; they execute this type of things extremely well, and I believe it's going to be a huge hit (even credit cards companies and banks are on board!)

I loved the idea of Google Wallet, but the experience is actually worse than paying with a regular credit card. No point of using it, so I'm not.

Other less-important things

Continuity, VoLTE, AirPlay, build quality, compatibility with my Bose Q15 headphones, exclusive applications, and I still have access to all the Google apps that I love (Maps, Gmail, Google Now, and Google+.)

What I'm going to miss

Android, Android L, Google's seamless integration everywhere, "Ok Google, how old is Angelina Jolie", and a pocketable-sized phone.

Last words

I'm really looking forward to get my new device. I know I'm going to love it, and maybe in a couple of years I'll go back to Android. Will see. It's happened before.

Fixed the RSS feed

My RSS feed wasn't working fine, randomly displaying old posts as new. I don't think it never worked fine since I implemented it myself, which is embarrassing.

But now it's fixed.

The problem? I was using the permanent URL of posts as the entry's unique identifier (GUID). This is actually perfectly fine, because the permanent URL of a post shouldn't change, allowing feed readers to cache downloaded (old) posts and never display them again as new entries.

But my URLs were in fact changing.

You can access this blog from two different URLs: blog.svpino.com and www.svpino.com. They both redirect to the same place. The way I was constructing the permanent URL of the post (and saving it in the cache) was by using the domain the reader was using. So, starting with an empty cache, if you accessed the site using blog.svpino.com, that particular post was saved in the cache using a permanent URL starting with blog (and not www.)

The RSS feed was later constructed by reading all the posts from the cache, so I was getting a mixture of blog and www URLs. This of course messed up with the feed readers, because they treated old posts as new posts if they came with a different ID (URL).

The hard part was realizing what the problem was. After that, the solution was to simply force all the permanent URLs to use blog.svpino.com regardless of the domain the reader was using.

Do you really need to change the browser's default scrollbar?

If you are a developer, you are probably with me. If you are a designer, you are probably screaming murder right now.

But think about it for a second; does it really makes sense to replace the default scrollbar in the browser with a custom one?

I've heard two different arguments:

  1. We need to change the default scrollbar here so users have the same experience across all browsers.
  2. We need to change the default scrollbar so it looks better.

The first argument doesn't really make a lot of sense: users use one and only one browser. Period. They don't open pages in multiple browsers and then compare to find the differences.

I feel more connected with the second argument (have you seen Windows' scrollbars?) But I still don't think it's a good idea. People know exactly how scrollbars look like in their operating system. They are used to them, and they don't have any reason to find them "ugly". Replacing the default scrollbar with a slick Mac-like scrollbar (which is what usually happens) might in fact cause confusion to them.

I'm pretty sure you can find 20 different reasons to change the scrollbars anyway, and that's Ok. But these should be the exceptions to the rule, and by default we should avoid doing it.

Besides, as a developer I can tell you that changing scrollbars is painful and error prone. And it doesn't work across all browsers anyway. And it's more development time, and more potential bugs, and more money from somebody's pocket.

Is it really that important?

Please, report all the bugs you find

Paul Irish in a Google+ post asking users to report the bugs they find when using a browser:

If your browser is crashing every ten seconds this might be hard for you to believe, but it's quite plausible for one person's browser to crash every ten seconds and 100,000 other people to see no crashes at all.

If you are a developer, you know that's exactly the case, however we easily forget about that and spend all our time complaining about other people's software when we should know better.

Basically, you should ensure the developers of your browser are made aware of your problems, so they can fix them, for you and others.

There's nothing more valuable to developers than feedback from their users. How else are we supposed to make the app better? Personally, I don't remember the last time I formally reported a bug (I can easily tell you when was the last time I bitched about a bug in Twitter), so the problem starts with me. I need to change that.

I won't claim we browser developers don't go through periods when our products have more bugs - we absolutely do - but I can guarantee you that not only the Google developers but the folks at Mozilla, Microsoft, etc. want to make the best products they can.

Sometimes we forget that behind the software we use there are really hard-working people trying to do the best they can to make us (users) happy. I definitively should think more about this every time I curse about IE9 not working as I'd expect.

If something is so bad you need to switch browsers just to keep your sanity, by all means do so; but whether it be for your old browser or your new one, following the steps above helps not only you but everyone else too.

Please, report all the bugs you find (if you are a developer, more so.) Not only bugs in your browser, but for every application you use. Something as simple as pressing a "Send report" button, or checking a box here or there can make a huge impact.

Again, here is Paul's post.

Do you really know how to use the viewport metatag?

I've been using the viewport metatag for over 4 years since I started working with responsive designs. However, I never truly understood it. Most of the time it's been a matter of copying the tag from my previous project and move on.

The viewport metatag is probably the single most important thing you need to know to make your web pages work well across different form factors, so I think it deserves a little bit more attention.

Here is the best reference I've found for the viewport metatag: Configuring the Viewport. There's a lot of content on that page, but it covers step by step everything you need to know about this topic.

(The link above is part of Apple's documentation, so don't be surprised if they only talk about Safari and the iPhone/iPod/iPad. The same applies to all the browsers and devices, so please look pass that small detail.)

If you are too lazy to read

I personally didn't care for a long time, and you deserve the same opportunity, so I understand if you are only looking for the quick copy-and-paste line. If that's you, here is your line:

<meta name="viewport" content="width=device-width,initial-scale=1" />

Use the above code, make your website responsive, and you'll be fine. Of course, depending on what you want to accomplish, the above line may actually screw your site, so if you are trying to do something different than a regular mobile-friendly website, get to work and read the documentation.

And why you should really care about this

Just in case you've never had to deal with pages in mobile devices, here is a little bit of history so you better understand:

Remember when Apple unveiled the iPhone in 2007? It was a new device that they knew was going to revolutionize the way people consumed content on the Internet. One of the strongest selling features of the iPhone back then was a very powerful web browser, but with great power comes great responsibility, so their engineers had a challenge to overcome: how to display all the existing web pages on such a small screen?

At the time, web sites were designed with a larger display in mind, usually wider than taller (the opposite of the iPhone in portrait mode), so Apple came up with the solution of making the browser lie about its current size. Although the original iPhone was 320px wide (in portrait mode), it reported a much larger display size (980px) in order to fit as much content as possible.

Thanks to this, here is how the CNN web page looks like in a small screen (actually, CNN has an optimized view for mobile devices, but you can click on their "view full site" link to get something similar to the images below):

As you can see, not the greatest experience; all the information is displayed in a tiny screen, making the text barely readable, and the links really hard to tap using your fingers. This is because the device is scaling the content to fit it all.

But what's the alternative? Let's imagine the browser doesn't scale the content to make it fit, and instead uses its current 360px of width (in a Nexus 5, 320px in the original iPhone) as the canvas to display the site. You'd get something like this:

Worse. Right? So scaling the page is a great solution to properly display sites, but I hope we all agree that neither of the options provides a great experience, so Apple came up with the viewport metatag as a way for developers to control this functionality.

Interested yet?

If you are, great! Here is the link again. If you aren't, well... you can come back anytime. I'm sure you are going to need it.

What does "mobile first" mean?

It doesn't mean that you need to code your mobile website first (as I've heard multiple times). Mobile first it's a paradigm shift to put mobile devices at the forefront of both strategy and implementation.

From Riley Graham's writeup:

Mobile first shifts the paradigm of a Web-site user experience. Instead of users’ viewing desktop versions of Web sites on their mobile device with some adjustments, users are now viewing sites that have been created specifically for their mobile device.

Usually, we go ahead and craft beautiful desktop experiences with mobile as an afterthought. Then we struggle to cram everything in the small form factor (so of course, we start hiding stuff.) Mobile first changes this dynamic.

This means designers should tailor site user experiences to the needs of users who are on the go and in multiple contexts.

It all starts with designers. They need to change the status quo, and start thinking about small before thinking big. This has the added benefit of less-cluttered interfaces since you need to consider right from the beginning what's really important and what's not.

Real estate in the web is really valuable, but sometimes we think it's cheap and misuse it. Mobile first changes that.

Developing Scalable Apps Using Google App Engine in Udacity

I learned about Udacity just a few weeks ago. If you haven't, go and check them out. In short, they are an educational organization offering massive open online courses (like another 1000), but with the particularity that they are trying to bridge the gap between real-world skills, relevant education, and employment, by offering courses taught by experts at leading tech companies.

What does that mean? Well, their catalog is up to date with relevant courses for software engineers. Real valuable stuff that's been used right now all over the world.

Check the list of courses by Google. I personally want to take them all, but I started with Developing Scalable Apps Using Google App Engine, and today I finished it with my exit interview.

Here are my thoughts on the entire course.

Note: If you are interested, but you don't like to pay for education, feel free to skip this post. You can watch the videos for free, but you have to pay for the full experience (certificate included). It's $150 well worth it if you ask me.

The classes and the instructors

Udacity has a very cool online classroom where you watch the videos and follow along with the instructors. It's very interactive, and I was surprised that some of the exercises asked for the URL of your project to evaluate your code automatically (it's called "autograder".)

The instructors were awesome, and despite me having over two years of experience using Google App Engine, I learned a lot of cool stuff. Of course, there were materials that I knew pretty well, but the course is very up-to-date.

The difficulty of the course will depend on your level. If you don't know Java, then it's definitively not for you. But if you do, you'll be fine; classes start from the very beginning.

The personal coach

That's right. You are assigned a personal coach that you can contact and ask questions about the course. I didn't use mine at all, but it's good to know somebody is there to help you out should things get complicated.

The autograder

I mentioned above that the automatic evaluation of your code was pretty cool, however, it was sometimes very spotty. I had to re-submit multiple times in order for it to work. Not sure what was going on, but it's something that Udacity / Google want to fix for sure.

During my exit interview, the coach was surprised about this when I told him, and he mentioned they weren't aware of this issue.

The final project

This is the best part. You get a final project that you have to complete (code). If you flew through the lessons, you'll have a hard time at this point. The questions are very good, and you'll have to code a lot.

They even have some very cool questions (requiring very cool answers), so be prepared to show some creativity.

Together with a zip file of your code, you also have to submit a document explaining your design decisions.

The evaluation of your final project

Somebody takes your code and makes sure you answered all the exercises correctly. I didn't like the fact that it takes a long time for them to complete the review (a full week in my experience), although you might feel that's quick.

My complain here is that the person evaluating my code sent back a couple of exercises as "not working" when in fact they were (unit tests included). It seemed to me that he/she didn't read the code at all, which was very heart-breaking. But I sent a note back, and they approved my solutions.

After you pass the final project, you'll have to schedule the exit interview.

The exit interview

This is a video chat with a coach. They want to make sure that it was really you the person who completed the final project, so they ask all sort of questions about your approach and your solutions. Nothing stressing at all (assuming it was you doing the code, of course.)

The interview took around 25 - 30 minutes.

The certificate

It's nice, but it's a PDF. For $150 I was expecting Udacity to send you a nice printout but they didn't. Not a huge deal, but if you want the paper, you'll have to print it yourself.

Conclusions

If you want to learn App Engine and you don't know from where to start, take a look to this course. Don't be cheap, pay for it, and get the full experience. You can pass it at your own pace, and you'll learn a whole lot of awesome things.

I'm a junkie of this stuff. I'm already planning my next one.