the joy of dying computers

Well, my trusty 4 year old macbook pro is finally dying, and being an unemployed/unemployable waste of air, my budget to build a new desktop (hackintosh of course!) to replace it (let’s face it, I can’t afford a new macbook pro or mac pro) is extremely tight.

So far I got a deal on an itx motherboard to go with the Ncase M1 I backed a couple months ago, along with a refurbished viewsonic VP2770-LED monitor on ebay, and I can scavenge my current SSD. I found a newegg coupon for 16GB RAM the other day ($139) and I just ordered a PSU for $94 (silverstone SFX 450W 80-plus gold) so now I’m just left needing a CPU to at least get the system up and running.

And on that note, FUCK microcenter.

The 4770K *SHOULD* be $279 + tax at microcenter.

And at every single store except the Tustin, CA location, it is. Here in California the 4770k is $359.99, or $319.99 with a bundled motherboard, which I don’t need.

So, if anyone has a spare Haswell i7 4770k they might be willing to donate (or sell at the price of an i5 ~$200-$250) I’d be forever grateful.

Sworkit mockups

So I admit it can come off wrong to criticize an application without offering an alternative, so I’ve taken some time to mockup just how good a native version of Sworkit could look and work on Android.

These are all very rough, and I’m not anywhere near finished creating mockups for every screen. Please note, the screen-captures from my phone are at 1280×720 resolution (with hardware buttons instead of soft-keys) whereas the mockups are made to target a Nexus 4 1280×768 resolution, with soft-keys.

First, a comparison of the existing application (left) and my mockups (right)

Overall, the only major changes are the move to a slide-out navigation drawer for access to settings, and a more holo-centric version of the “Cards” UI style. In addition, There’s plenty of room on-screen for quick access to your most recent workouts to repeat them without any hassle.

The workout selection list is largely unchanged too, simply conforming to the HOLO theme, and removing the “back” and “more” buttons up top in favor of using the “UP carrot” in the top action bar.

And the custom workout screen, compared to a workout “Queue” system. Of course a queue system doesn’t have to replace the custom workout option, but I think it’s a better feature to implement earlier than fully custom workouts, especially with the randomization that Sworkit can already employ.

And of course, the settings menu compared to a Navigation Drawer. You could go even further, and embed a switch/toggle for the “30 Second Break” right into the drawer for super quick access to this setting.

EDIT: 3:50pm, 8 Oct, 2013 – Updated the navigation drawer mockup to show icons in the drawer. All icons used in the mockup are stock Android, available for free from Google in vector format.

And lastly, to expand on some of the drill-down pages in the Settings menu, I would break apart the user profile and goals into separate screens, and incorporate things like TDEE calculation, more accurate calories burned estimation based on fitness profile, etc.

And an idea of what an expanded “Goals” screen might look like, with linked sliders so that adjusting minutes-per-day, minutes-per-week, or days-per-week will all update the other sliders for best-fit goals.

And of course, all of the above could easily translate to the “Holo Dark” system theme with little to no modification really.

Second class Android

It should be no surprise to anyone here that I’m a big fan of Android, though I’m by no means a “fanboy.” I’ve had a smart phone since the days of the original Handspring Treo, and since then I’ve used palm OS, windows mobile, Symbian, iOS, and Android devices. Really the only mobile platforms I missed were WebOS and meego (both died to quickly.)

The number one reason I settled on Android was the extremely tight/core integration of Google services, and the generally “Open” nature of the platform on the whole.

I like to hack and tinker with my electronic devices, and Android affords me the greatest opportunity to do so.

That said, it’s extremely disheartening to see that after 5 years of rapid development, Android is still a second class citizen when it comes to many cross-platform applications.

A recent example of this is a popular exercise app, Sworkit.

The paid/pro version of this app ($1) has an overall rating of 4.6 on the Play store. And the free version has an overall rating of 4.5, and both apps combined have an “install” base of ~105,000-510,000 users according to the ranges indicated on their product pages.

And Sworkit for Android is a borderline unusable iOS port, and an example of a terrible developer pushing crap as quickly as possible to make money, instead of focusing on quality.

Here’s a few or the biggest problems with Sworkit for Android:

  • Sworkit isn’t native, but an extremely poor performing web-wrapper, using Cordova.
  • Sworkit completely ignores every Android UI guideline. This is a huge, HUGE issue. Menu’s don’t work the way they should, There’s no action bar, nav drawer, view control, etc.
  • Sworkit completely ignored the systemwide “Holo” themes, instead using UI elements straight from the iOS app that don’t fit with Android at all.
  • Sworkit largely ignores hardware buttons which either don’t work as they should (back causes endless loops in many screens), crash the application, or don’t do anything at all (e.g. menu button)
  • Sworkit uses built-in, pre-recorded voice files instead of utilizing the Android TTS services, so the only language it supports is English.
  • Sworkit embeds assets (e.g. system fonts like Roboto) instead of calling them from the operating system framework.
  • Sworkit even ignores common APK structure, placing all drawables into the /assets folder instead of the /res folder.

This is by no means an exhaustive list of all the problems with Sworkit for Android, but it’s definitely some of the most glaring issues.

I don’t really know how else to say this, but to anyone developing for mobile platforms, your applications need to show that you actually care about them. Android users by and large want apps that look and feel like they belong on Android, not iOS or web ports. Just like iOS users want apps that look and feel like they belong on iOS.

If you’re going to develop for multiple platforms, take your time. Learn the platform. Use it’s strengths wherever possible, and only develop custom workarounds in the absolute worst/last case scenario.