Finally Heard … “Sanity” in Mobile Application Development

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

Finally, a refreshing, and sane way to look at the mobile app development in Dan Kim’s, “Myth debunking: WebViews suck, everything should be native” blog post.

Thank you Basecamp.

Agree wholeheartedly: You don’t need to be pure native or have 60fps on every screen – to make your customers happy.

This leads to an interesting thought: are junior devs being led astray by so much emphasis on performance? (thinking #perfmatters etc). What about “premature optimization is evil”?

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” – Donald Knuth

I use Basecamp’s app, and I can vouch for it. It’s completely indistinguishable from native.


Let’s have freedom from the “native trap”. It has been sucking up our lives in endless tedium, slow release cycles, impossible demands. Pure native iOS (and even Android) is inaccessible, elitist, anti-web – even if it wins now.


 

Aside – the referenced TurboLinks library is an interesting approach to the React/AngularJS methodology. (Probably not what I’d choose, but a nice approach nonetheless.)

 

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Android App Development, AngularJS, Finding a Mobile/Web Developer, HTML5 Apps, Hybrid Apps, IOS App Development

Legacy Work is where Grit Matters

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

I was recently reading a great article on techniques for rescuing legacy code.

And it occurred to me that difficult, hard-to-manage legacy projects present a great business opportunity. I see a lot these lately, with legacy PHP, Magento, ASP.Net or classic ASP, ColdFusion or Perl/ModPerl.

Even though they are older technology, they can be great projects because they have the following qualities:

  • Very important and valuable, sometimes high-profile
  • Requiring specialized skills that may not exist anymore (or be worthwhile to learn today)
  • Often requiring short or urgent timelines
  • These are often projects that noone else wants to take on

Of course, for the same reasons, these projects can be treacherous, stressful and fraught with dangers.

Having met a lot of resistance from developers to work on these projects, I also know these projects require a lot of grit. Working in the swamp isn’t fun. It’s hard, sometimes boring and sometimes thankless work.

The kid-centric culture we so often see within startups and IT – the ping pong, games and supercharged soft drinks – can emphasize the fun at the expense of seriousness and responsibility of the situation.

What’s needed to attack these types of projects is a mature, balanced, adult outlook, as well as some willingness to tolerate pain. I guess you’d call that grit or being “grown up”. However, I’ve also come to believe that having fun is the best way I know to become productive. And, that once work stops being fun, it’s just a matter of time before the quality of our work goes down hill. (We can’t get rid of all the soda pop, or we go flat).

So for legacy and difficult projects, a company’s culture can be very important for this type of work. Here are some cultural qualities I think are important:

1. Toughness and grit
2. Ability to see “fun” despite difficult situations
3. Ability to take on responsibility
4. Calmness
5. Willingness to work behind the technology learning curve for awhile

Despite all that, I’ve had times when these projects overwhelm you, frustrate you, and seem so hard they really do just want to make you cry. For that reason, I believe having empathy can go a huge way in an organization. These types of workers can often give a worker a “shoulder to cry on” when things become really tough.

(Do a good deed and be empathetic for your co-workers today.)

What qualities have you’ve seen as important on legacy projects?

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Content Management, E-commerce, Legacy

5 Reasons Big Sites go Mobile-Only and not Responsive

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

Mobile-Only (MO) and Responsive Web Design (RWD) are both great techniques to approach mobile-friendly web sites. (For background, see Mobile SEO: Responsive Design vs. Separate Mobile Site vs. Dynamic Serving.)

yahoo_mobile

Yahoo uses “Dynamic Serving” to send an easy-to-click, mobile-optimized site.

In fact, RWD is the choice for redesign sites, simple sites and smaller sites (roughly those under 100 pages). For example, in 2014-2015, many “brochure” site owners switched over to SquareSpace.com and Wix.com. They realized they needed to be mobile-friendly – and could use a redesign at the same time. Because the site was small, the content was easy to port over, and – no need to hire an expensive web designer. RWD is a great compromise here, because with these stripped-down sites, the difference between mobile and desktop is minimal anyway.

It’s different for big sites.

For these site owners, here are some facts:

1. Google just wants your site to be mobile-optimized. They don’t care how you approach it.

Even though Responsive Design is Google’s recommended approach, but for SEO, they aren’t going to penalize the big players for having Mobile-Only sites.

Dynamic Serving and Separate URLs will only be penalized by Google only if they are implemented incorrectly.

In fact, Google.com uses Dynamic Serving to bring up a mobile friendly version of it’s site! (And so doesn’t Gap.com, Facebook.com and Yahoo.com)

2. On an existing, large, very complex or legacy desktop web site, RWD can be extremely costly to implement.

Why? Because a responsive design almost always changes the look of your desktop site – effectively forcing a redesign. In addition to unintended changes, RWD can introduce hard-to-find bugs throughout an existing, working desktop site.

It’s much less expensive to apply a lightweight, independent, skin or theme to an existing site, than to rework the existing desktop site.

As mentioned above, this isn’t going to be a problem on small and simple web sites – or sites which are being built entirely from scratch.

What about having to maintain multiple themes? Isn’t that more costly?

Yes, it can be. However, if your site is properly architected, you should be able to apply a mobile “skin” or “theme”, while keeping your core logic and backend. This means you re-use most of your existing site. And your mobile theme is simpler than a combined, RWD, mobile/desktop theme.

3. Light payload for small mobile devices often favors MO.

Google also uses “Dynamic Serving” approach for it’s mobile-optimized site. The content changes, because on mobile they encourage people to download the app.

Why should 100% of the desktop content be downloaded for a tiny mobile device, only to have 50% of the content hidden from the user? Wouldn’t it be better to deliver only the minimal amount of HTML, CSS and Javascript the user needs? After all, the point is to give users on mobile a better experience.

4. Completely different content on mobile devices can be difficult to achieve using RWD.

Users on mobile devices may be in an entirely different environment than tablet or desktop users. For example, a desktop user may be in an office doing research on your product – very technical, lots of careful reading and clicks etc. On the  other hand, a mobile user might be in a car on the way to the office (hopefully not driving!) and looking for a phone number. Mobile users favor download speed, swipe screens, and large tap targets to avoid “fat fingers”!

Of course, you can use techniques (like @media queries and flexbox) to change content based on screen size. However, this technique starts to break down as your mobile content becomes very different from desktop. For example, on desktop you prefer an standard photo gallery, but on mobile you prefer a swipe-style photo gallery.

5. People have lots of different opinions on this topic. 

For example…

  1. Responsive Web Design is not the Future
  2. 11 reasons why Responsive Design isn’t that cool!
  3. Mobile SEO: Responsive Design vs. Separate Mobile Site vs. Dynamic Serving
  4. You May Be Losing Users If Responsive Web Design Is Your Only Mobile Strategy

To be fair – both Apple.com and WSJ.com are using RWD. Finally, from www.imediaconnection.com – “Looking at the 100 top-trafficked websites in the world reveals that 83 have dedicated mobile sites, 11 use responsive design, and four just have old-fashioned, non-responsive design.


 

TLDR: As with most things, there isn’t a once-size-fits-all approach to MO vs RWD. You need to take your site into account to determine which approach works best for what you have.

Best of luck with your site optimization! Contact me if you need help on your website mobile optimization project.

 

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Finding a Mobile/Web Developer, Mobile-Optimized Web Sites

Hybrid Mobile Apps and where Material Design Fits In

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

I found this article by John McMahon, Starter Inc. very insightful about where Material Design fits into the “battle” of Hybrid mobile development. Ultimately, the weight of native mobile application development is too much… too expensive, too time consuming and too slow. The web must be “brought back to mobile”. It needs to be supported, and highly performant – just like native. And we need a common “UI” or look so apps are more uniform across devices.

https://medium.com/@TechnoCharms/the-war-for-control-of-the-mobile-web-is-about-to-heat-up-47b73ee501fe

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Finding a Mobile/Web Developer, HTML5 Apps, Hybrid Apps, Mobile-Optimized Web Sites

Great Video on Unit Testing

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

Watch this video to explain how unit testing can improve the speed an accuracy of your programming.

p.s. I found this link on http://www.mwkrom.com/.

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Uncategorized

How to Perform a Complex Magento E-Commerce Upgrade – Part 3, “Typical Problems”

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

The following article is part 3 of a multipart series on performing Complex Magento Upgrades (versions 1.4 – 1.9 CE with many theme changes and custom modules). Part One, Preparation and Part Two, “Rock the Diff”

Problem: Forms no longer submit, or they submit, but appear to “do nothing”.

Solution: Inject the following code into the form tag of your template:

<?php getBlockHtml('formkey'); ?>

Explanation: You’ve modified a template. Magento introduced Cross Site Request Forgery (CSFR) protections in CE 1.8, injecting “formkeys” in all forms. Any forms which are missing this block, silently stop working.

Problem: Catalog search returns different results.

Solution: Consider changing to a “full text” or “combined” search type. See See jharrison’s Stack Overflow Answer.

Explanation: The “like” search was changed from “AND” to an “OR” search sometime after 1.4.

// From /app/code/core/Mage/CatalogSearch/Model/Mysql4/Fulltext.php
$likeCond = '(' . join(' AND ', $like) . ')'

whereas version 1.9 includes

 $likeCond = '(' . join(' OR ', $like) . ')'

Problem: “Forgot Password” and “New Registration” email no longer contain passwords 

Solution: Update your customized email templates. Include a “password reset” link instead of clear-text passwords. You can do this within Admin -> System -> Transactional Emails.

Explanation: Magento (finally) stopped storing passwords in clear-text, and now requires a link to reset password. If you customized email templates, you’ll need to copy from a clean version of the site. See: http://magento.stackexchange.com/a/
46793/24381
and http://www.neubreed.com.au/blog/2013 /03/magento_upgrade_killed_forgot_password

Problem: Custom fields not appearing on back or front end.

Solution: Modify your installation scripts (e.g. app/code/local/Acme/
Customer/sql/acme_customer_setup /mysql4-install-0.1.0.php), instructing Magento which form fields should appear:

->setUsedInForms(array('adminhtml_customer'))

becomes:

->setUsedInForms( array( 'adminhtml_customer', 'customer_account_edit',
'customer_account_create', 'checkout_register'))

Explanation: Magento 1.5 added a new table, “customer_form_attribute” which identifies where fields appear. This table should be populated for your custom field to appear. You can manually populate it, but it’s much better to add to the setup script, which is run when the module is installed.  (Delete from table “core_resource” table to re-run the install scripts).

Problem: Order emails not being sent

Solution: Install http://support.xtento.com/wiki/
Setting_up_the_Magento_cronjob

Explanation: Later versions of Magento require a cron task to be running. The cron task polls the site and sends emails when required.

Problem: Fields not saving in admin section.

Solution: Modify your custom module setup script to include:

setData("is_system", 0)

Explanation: The table,

customer_eav_attribute

has a new column, “is_system”. Make sure this column is being populated by setup script.

Problem: Errors in templates using loadParentProductIds() function.

Solution:

$parentIdArray = $_product->loadParentProductIds() -> getData('parent_product_ids');

becomes:

$parentIdArray = Mage::getModel('catalog/product_type_grouped') -> getParentIdsByChild($_product->getId());

Explanation: loadParentProductIds was deprecated in a version after 1.4


 

Hopefully these tips help you with your Magento upgrade. Reach out any time you need some help with your migration!

 

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Legacy, Magento

How to Perform a Complex Magento E-Commerce Upgrade – Part 2, “Rock the Diff”

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

The following article is part 2 of a multipart series on performing Complex Magento Upgrades. Part One, Preparation

Now that you’ve done the preparation, let’s begin the migration.

This approach has you carefully choose the modules and theme changes you want. It’s the “Manual Merge” method from Brett’s post on Magento. I prefer this approach to Duntuk’s approach – which works – but overlays the new installation “on top” of your old site. I prefer to carefully pick the changes. It takes more time, but is more “clean” in my opinion.

Here are a few additional links:

  1. Magento Offical Upgrade Process (magentocommerce.com)
  2. Upgrade Trouble shooting (appseconnect.com)
  3. Brett’s Stack Overflow post on Magento (stackoverflow.com)
  4. Theme Review (www.sitepoint.com)

Let’s overwrite our “upgrade” 1.9 database with the current (old site) MySQL database.

First, disable Magento’s caches. Then overwrite the database in the upgrade site.

cat pristine_databases/acme_old.sql | mysql acme_upgrade

And configure the links within Magento for your development domain. 

echo "update core_config_data set value = 'http://upgrade.acme.com/' where path = 'web/unsecure/base_url'; update core_config_data set value = 'http://upgrade.acme.com/' where path = 'web/secure/base_url';" | mysql acme_upgrade
echo "update core_config_data set value = 'matsinc.com' where path = 'web/cookie/cookie_domain'" | mysql acme_upgrade

Run the following SQL to truncate your old logs.

echo "truncate dataflow_batch_export; truncate dataflow_batch_import; truncate log_customer; truncate log_quote; truncate log_summary; truncate log_summary_type; truncate log_url; truncate log_url_info; truncate log_visitor; truncate log_visitor_info; truncate log_visitor_online; truncate report_event; truncate report_viewed_product_index ;truncate report_compared_product_index" | mysql acme_upgrade

Next, install the Open Source command line tools for Magento, “magerun98″.

wget https://raw.github.com/netz98/n98-magerun/master/n98-magerun.phar

Run database upgrade to update the database structure for the new version.

php n98-magerun.phar sys:setup:run

In general, I’ve found these database upgrades work smoothly. Hopefully, by the time it completes, you can view your upgrade site – but without any custom modules or themes.

Now, it’s time to start merging in files from the old (old.acme.com) installation into the new (upgrade.acme.com).

An effective technique I’ve found is to perform a 3-way comparison between pristine1.4.acme.com / old.acme.com / upgrade.acme.com.  With a 3-way comparison, you can clearly see any changes that past developers have made, then synch the changes to the new installation.

Typically, I’ll use the free, kdiff3, which has an excellent visual display for 3-way comparisons. Although it works better on a PC than a Mac, it’s a great tool for complex diffs. However, for 3-way diffs, it’s missing the ability to synchronize entire folders easily.

I recently found Araxis Merge ($269, 30-day evaluation), and I love it. It has a “drill-down” interface which is more linear, but feels more accurate. The key is the ability to click a folder and copy – so you don’t have to visit the shell or Finder.

Again, I’m assuming that you have a complex upgrade and changes are sprinkled throughout the Magento installation. For a simple upgrade – you won’t need these tools.

Start by merging the following folders.

/app/etc/modules/
/app/code/community
/app/code/local
/app/design/frontend

As you make each set of changes, I recommend creating a separate Git commit. This allows you to comment on the merge, and let’s you easily go back to any point in the process.

kdiff3 - 3 way merge

kdiff3 is a free tool to perform 3-way comparison of folders. Visual display (green for a match, red for a mismatch) let’s you quickly see diffs inside folders.

Araxis Merge

Araxis Merge is an excellent tool for performing 3-way merges which require synchronization of entire folders.

test

The ability to Command-click a folder and copy to the second or third location is key with Magento upgrades.

In part 3, I’ll cover, “Common Upgrade Problems”. Stay tuned!

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Legacy, Magento

How to Perform a Complex Magento E-Commerce Upgrade – Part 1, Preparation

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

The following article is part 1 of a multipart series on performing Complex Magento Upgrades. Part Two, “Rock the Diff”

Upgrade from CE 1.4 to 1.9. The installation has many theme and module customizations applied to it.

Here’s how to tackle a project like this.

Preparation, Preparation, Preparation

Like painting a house, preparation is key. Install 4 – yes 4 – sites prior to beginning the upgrade. In my case:

  1. Pristine 1.4 (base installation of Magento 1.4, no customizations)
  2. Pristine 1.9 (base installation of Magento 1.9, no customizations)
  3. Old (untouched copy of existing, old site)
  4. Development (your new site, with a clean Magento 1.9 install)

Old, community editing (CE) versions can be found here: Magento Downloads click “Release Archive”.

Each installation should be done locally (which means running OSX or Linux) on a fast machine. Being local means you can quickly compare files using visual comparison tools. No need to push changes to a server. Speed really matters when you are comparing 36,000 files.

Give each site a clearly, identifiable domain name, such as “pristine1.4.acme.com”, “pristine1.9.acme.com”, “old.acme.com”, “upgrade.acme.com”.

Why do this?

Your biggest enemy is your own confusion as you dig into the thousands of files in a Magento installation.

During the migration process, you will constantly be asking yourself, “what is the baseline?” For example, because passwords were hashed after version 1.7, they can no longer be sent via email. If you had customized your email template, you’ll want a copy of the pristine 1.9 email template, which now contains a password reset link instead of plain text password.

The “baseline” will also inevitably include “how did it work before”? (And, yes, this question will come up after you’ve taken the old site down.)

The 4 sites let you compare files using a three-way-diff. Now you can see what changes other developers had made.

I can’t stress how important it is to always have a (quick) answer on-hand for your baseline questions.

Warning: when you switch administration between multiple sites, clear your cookies. If you go back to the administrative login screen after attempting to login, you probably need to clear cookies.   

I also recommend the following:

  • Document all modules in your installation, including version numbers. You can find the modules in /app/etc/modules and version numbers in their corresponding /etc folder within /app/code/local or community/ [company]  /[modulename] /etc/config.xml
  • Add all files to a git repo. Git is fast and allows you to “play” or “experiment” freely (e.g. make lots of changes) without feeling like you’re going to accidentally leave something in a broken state. Use Atlassian SourceTree or Tower to visually compare and roll-back changes  you’ve made.

Part 2, “Rock the Diff”

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Legacy, Magento

Share Constant Values between AngularJS and NodeJS

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

Suppose you have a client-side configuration as an Angular module like this:


angular.module('config', [])
  .constant('configuration', {
    API_END_POINT: 'localhost:3000',
    APP_END_POINT : "localhost:9000",
    "ORIGIN_HOST" : "localhost:3000",
    'ENVIRONMENT' : 'dev'
  });

You’d like to pull these constants into your nodejs environment to keep constants canonical. You don’t want some super-complex module to make things messy.

Simply define a “fake angular” on the server-side, then grab your constants.

/* inside nodejs now */
var CONSTANTS;

angular = {
	module : function() {
		return {
			constant: function(name, constants) {
				CONSTANTS = constants;
			}
		}
	}
}

require("../web/scripts/config.js");
console.log(JSON.stringify(CONSTANTS)); // easy peasy

Thought that might help a few of you struggling with sharing code between Angular and node apps!

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in AngularJS, NodeJS

Observation: Mobile is Looking more like the Web

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare

It’s funny. The Web just can’t be kept down, and it’s spirit and character are still alive. But things are definitely different after the mobile revolution started.

Here’s a few things I’m seeing:

Developers are worn out trying to make apps work everywhere.

It’s amazing to think that when you said “app” 8 years ago, you meant “iPhone”. There was simply nothing else that mattered. Here were my thoughts in 2010, still on my Blackberry (admittedly a bit frustrated with the iPhone “thing”).

The growth of Android has been phenomenal and this changes things a lot. The “serious app” today must include an IOS client UI and an Android client UI, both linking to a common RESTFUL back-end usually Rails, .NET or Java Servlets.

But even having done all that work, developers are uneasy. What will a 3rd growing platform mean, maybe Windows Phone, Tizen, Firefox OS becoming more successful? It’s a huge pain point.

In this climate, when new functionality is needed, where are developers going to add it?

I think a lot of them are choosing the back-end.

Of course, they could use a low-level C++ layer for core functionality and recompile it into their apps.  They could also use cross-platform languages like Javascript or Java for canonical functionality.

Adding functionality to the back-end is going to come at the expense of additional network calls and offline capability.

People really miss hyperlinks and want them back.

I’m seeing more emphasis on “deep linking” between apps.

The two major initiatives are Facebook’s AppsLinks and Google’s App Indexing. This technology will be very important in making it easier to jump between apps – similar to how links work on the web.

I’m sure there will be at least a few startups that ride the wave of deep linking and indexing to success.
More mixed cross-platform (HTML5) use, but native UI is still where it’s at. 
I’ve been writing about HTML5 for a long time. It’s coming along. But the progress is slow, and it’s fraught with new technology that can collapse beneath your feet when new versions come out – or whole swaths of devices that aren’t compatible. Finally, people still associate a great UI with native and that isn’t changing for a long time. Maybe it will never change. Native still rules.

More ongoing maintenance. 

The appealing idea of apps for developers was that you could launch a $.99 app in 2008, make money and never have to bother with it again.

That’s not what’s happening now. Because back-end is becoming more important, you’re going to have upgrades, backward compatibility, changes to 3rd party APIs and libraries, and it’s all going to come at the wrong time (like when you are launching another product/site etc). It’s the kind of stuff you have to pay to get done, and is weeding out a lot of first-generation apps.

Take the transportation apps developed for the MBTA in Boston. The first generation were done around 2008-2010, mostly done by college kids. Noone has made much money on these apps. So today, about 1/4 of these that are broken, outdated, or just no longer maintained. Keeping up with the API changes on two platforms is really, really time-consuming (I speak from experience – I’ve been doing it).

Well those are my thoughts for the day. Let me know what your seeing out there (in the comments)!

FacebookTwitterGoogle+PinterestWhatsAppStumbleUponShare
Posted in Android App Development, HTML5 Apps, Hybrid Apps, IOS App Development