Tuesday, April 3, 2012

10 Reasons a Mobile Commerce Strategy is a must in 2012


.
For your eCommerce business, you are always looking for more sales.  It's like an easter egg hunt.  You pick through this bush, poke through that pine straw, continually foraging for an incremental conversion.  "OH! Look, there's 3 hiding in here!  Oh sweet! I found another."  It never stops.  It doesn't matter the amount of new business that comes from a new channel, if it adds even one, you do it. 

So it comes as a surprise to me that so many eCommerce companies haven't already jumped on the mobile bandwagon.  According to Nielson, 66% of Americans ages 24-35 own a smartphone.  Does that age range sound like your target market?  It shouldn't shock you either that people are using these mobile computers to make shopping decisions, look for coupons, visit their favorite sites and even make purchases.  

Now it's up to you whether you want a mobile commerce website or a full blown native ecommerce mobile application.  However, I will say that ideally you would have both and your app would simply be a native wrapper to your mobile site.  This will keep your cost lower and your maintenance easier.  

Still not convinced? Here are the top 10 reasons you should at least have a mobile shopping website, if not a full blown mobile shopping application, in your plans for 2012: 

  1. When your ecommerce site looks horrible on a mobile device, you look horrible.  Users hate broken things, it makes them feel like you don't care about their experience or want to put in the effort to win their business.  And there are people out there who are already doing it and doing it right, you're falling behind. 
  2. People are starting to use their phone to do searches they used to do on their computers.  Why?  Many people use their work computers as their only computer and don't want their IT departments snooping through their searches.  If your site isn't optimized for mobile, it's unlikely to show up. 
  3. Applications to purchase goods online that are "scanned" or found by a smartphone user are already on the market and will continue to eat into retailer's sales until they are countered. (Only applies to brick and mortars)
  4. Smartphone apps and websites are not a fad, they're here to stay.  Similar to how the original web ousted desktop applications for the mindshare of users daily computing, the mobile web and mobile applications are doing the same thing to the original web.  Think about it, are you going to run home and get on your computer to figure out if that dress was $60 or $70 at your favorite store or are you going to look it up on your phone?  Convenience trumps functionality, always. 
  5. Phone conversions are not the same sales.  You're going to capture new customers that you otherwise would have lost because they aren't searching for you on their computer. 
  6. You look more cutting edge, giving you a psychological advantage over your competitors.  They may not buy on the mobile, but the fact they were able to quickly check a product from their phone on your site will not leave them and will influence future purchasing decisions. 
  7. Mobile devices add a new dimension to the game, location.  Now, especially if you are brick and mortar, can target users based on their proximity to your services, or to establishments that are target rich for your types of customers.  This leads to higher conversion rates. 
  8. Consumers are using their phones to search for coupons while in a store.  They are primed to buy, otherwise they wouldn't be in a store.  But awesomely, they are looking on their phone for better deals.  If you aren't in position to be presented to this customer, you don't have any chance at these incremental sales. 
  9. It's and under-served market!  You could very well be the first one in your niche on the mobile web!  That's huge!  The first one to a market is typically going to have an advantage.  If you could reset the clock and be the first on google in your space (assuming you weren't), wouldn't that turn the tides a bit for you?
  10. It's easy.  It's a small screen and plenty of tools exist to put your content at the hands of mobile users. 
So good luck in your 2012 push to glory.  When in doubt about mobile, I would side with doing something. It's better than having nothing and looking lazy to your consumers.  

Wednesday, February 17, 2010

Windows Phone 7: Will the browser suck like windows mobile did?


.
So the big news out of Redmond recently is Windows Phone 7, the new mobile OS from Microsoft. Slick demo videos and hoopla combine to make this all really confusing. I'm frantically looking for technical specs on this and I'm having issues. From what I can tell, we won't know more until the MIX conference.

As a mobile application developer, I find this very intriguing but I need DETAILS. Is the browser the same piece of crap that Windows Mobile was running? All that POS consisted of was old school Pocket IE with a new name. Trust me, it was bad. It couldn't even handle a keypress or cursor event in javascript... Hopefully though, it will be fine. Ars Technica reports it as " unsurprisingly, still Internet Explorer. Claimed to be somewhere between IE 7 and IE 8, the new browser is, as with the rest of the platform, fully multitouch friendly. One thing not found in the new browser is Flash." We'll see.

Another question is what kind of development tools will we have for this? The obvious answers aside "It's Visual Studio duh", I would like to know things like will we have straightforward access to the hardware? Simple management of system resources like network adapters and contacts? Most of these things were done with extreme hacks and 3rd party libraries in prior versions. One this is for sure though, apps on prior versions of windows mobile will NOT run on the new platform. Could mean quite a bit of delay before corporate adoption (on rugged handhelds for example).

My ranting aside, below are some links I've dug up that cover this event. Below that is the marketing video showing the OS.

I will be doing a series called "My first app" in which I will be doing a sample iPhone, Android, Blackberry and web app. While the goal is to help people getting in to development find their way, it's also an opportunity to grade the different dev platforms against each other. Would love to add windows phone 7 to the list.



Coverage:

windows 7 phone series starts from scratch

Hands On with Windows Phone 7 Series

Microsoft unveils Windows Phone 7 Series hotness

Tuesday, February 9, 2010

Using Reflection in C# - Copying objects across namespaces


.
You may not find yourself in this situation that often, but sometimes you have two objects of the same structure who find themselves in different namespaces and you want to copy one to the other. An example of this is having two webservices who use the same Customer object. If a return of a Customer from one web service is to be used in the other, you face a sticky situation. The second service won't accept the return from the first without some tricks because they are in different namespaces.

This can be solved 3 ways that I'm aware of. Of the 3, I prefer to use reflection. The first is to hack your Reference.cs files to remove the namespacing and make them match. The problem with this is that you have to do this each time you update your reference from the WSDL. Not good in my opinion.

The second way is to implement the iConvertible interface, something I find overkill.

The third way is to copy all of the properties of the first object to an empty copy in the second namespace using reflection. Below is a method called ObjectCopy that will do just that.



//Use System.Reflection at the top of your file

public Object ObjectCopy(Object from, Object to)
{
Type fromType = from.GetType();
Type toType = to.GetType();

PropertyInfo[] fromProps = fromType.GetProperties();
PropertyInfo[] toProps = toType.GetProperties();

for (int i = 0; i < fromProps.Length; i++)
{
PropertyInfo fromProp = fromProps[i];
PropertyInfo toProp = toType.GetProperty(fromProp.Name);
if (toProp != null)
{
toProp.SetValue(to, fromProp.GetValue(from, null), null);
}
}

return (to);
}

Monday, February 8, 2010

Please Make A Note: Posting Source Code in Blogger


.
Please Make A Note: Posting Source Code in Blogger

Blog post detailing how to add source code to a blogger blog post. Thanks!