Google Music Store tendrá una fuerte integración con Google+

Google Music Store tendrá una fuerte integración con Google+:

Aunque en mayo Google abría uno de los servicios más esperados, no se puede decir que Google Music haya cautivado a la crítica ni a la comunidad. Su lanzamiento fue muy discreto, lanzado en forma de beta muy cerrada, y como un servicio que permitía almacenar nuestra música para poder acceder a ella a través de nuestros dispositivos Android o desde cualquier navegador, aunque poco más.

Eran muchas las publicaciones que hablaban de un lanzamiento forzado, debido a las presiones y a la creciente competencia que había salido, con muchos nuevos competidores como Amazon que entraban fuerte en el sector con servicios como Cloud Drive. Y también, muchos los rumores sobre un posible lado oculto de Google Music que aún no había visto la luz.

Parece ser que poco a poco se van desvelando los detalles de lo que será otra parte del servicio, Google Music Store, que vendría a ser el equivalente a iTunes pero bajo la marca Google. Con una integración total con los cada vez más numerosos dispositivos Android, parece ser que no será lo único con lo que esté íntimamente relacionado. Según leo en TNW, parece ser que Google Music tendrá una fuerte integración con otro de los lanzamientos estrella de este año: Google+, algo que, en mi opinión, podría ser todo un acierto.

Google está haciendo que todos sus servicios se integren con la nueva red socia. De momento, esta es accesible desde la popularmente llamada barra Google, que parece estar cambiando constantemente, y desde la cual además de entrar en el sitio también podemos realizar muchas acciones sin salir de la página en la que nos encontramos.

Lo que se sabe de la nueva integración de Music con Google+ es que habría un sistema de recomendaciones en el que de momento estarían disponibles las pistas de las discográficas con las que el gigante ya tiene un acuerdo. Entonces, los contactos a los que hemos recomendado un determinado tema, podrían escucharlo de manera gratuita pero solo una vez, pudiendo elegir si comprar –al precio de 99 centavos— o no comprar dependiendo de si le gustó.

Yo esperaba ese momento con ansias.

Una historia de internet | Seek death and ye shallfind it.

Internet Story from Adam Butcher on Vimeo.

Una increible historia.

Improve The User Experience By Tracking Errors

Improve The User Experience By Tracking Errors:

It’s easy to see your top-visited pages, navigation patterns and conversion metrics using visitor-tracking tools like Google Analytics. However, this data doesn’t show the roadblocks that users typically run into on your website. Tracking and optimizing error messages will help you measurably improve your website’s user experience. We’ll walk through how to add error tracking using Google Analytics, with some code snippets. Then, we’ll assemble the data and analyze it to figure out how to improve your error message drop rates.

What To Track

The most helpful errors to track are form-field errors and 404 pages. Form-field errors can be captured after the form’s validation has run; this can be client-side or server-side, as long as you can trigger a Google Analytics event when an error message appears to a user. (We’ll be using Google Analytics in this article, but you can apply these concepts to many visitor-tracking tools, such as Omniture and Performable.)

Form-Field Errors

Forms that allow users to create an account, log in or check out are the places where most visitors will hit stumbling blocks that you are not aware of. Pick pages with forms that have high exit rates or that have high total page views but low unique page views. This could indicate that users are repeatedly trying to submit the form but are encountering problems.

The easiest way to track form-field errors with Google Analytics is to track an event each time a user sees an error message. The specification for _trackEvent is:

_trackEvent(category, action, opt_label, opt_value)

If the form is for signing in and the user submits an incorrect password, I might use the following code:

<script type='text/javascript'>
  _gaq.push(['_trackEvent', 'Error', 'Sign In', 'Incorrect Password']);
</script>

If possible, store the error message’s text as a variable, and call this variable within Google Analytics’ event tracker. This way, as you change the text of the error message over time, you can measure the differences between the versions. For example, in PHP, I might write:

<?php
  $message = 'Incorrect password';
  if ($message) { ?>
  <script type='text/javascript'>
    _gaq.push(['_trackEvent', 'Error', 'Sign In', '<?php echo $message ?>']);
  </script>
<?php } ?>

If it’s possible for the user to receive more than one error message on the page at a time (for example, if they’ve missed more than one field in a form), then you might want to store all of the messages in the same event tracker. Use an array, or concatenate them into the variable that you call in your event tracker. You might see that a user has attempted to skip all of the fields in a form; this could indicate that they are testing the form to see which fields are required and which are optional. You’ll notice this if you have tracked an event that includes all missing fields in the same event. However, storing all of the messages in the same event might prevent you from tracking the effects of individual error messages over time, so begin by tracking each error message separately.

404 Pages

You might already know how many times your 404 page is being viewed, but do you know which URLs the users were trying to reach, or what websites are referring to those URLs? By adding a tracking code to your 404 pages, you can see both. The following snippet will include the URL that generated the 404 error and the URL that linked to that page:

<script type="text/javascript">
  _gaq.push(['_trackEvent', 'Error', '404', 'page: ' + document.location.pathname + document.location.search + ' ref: ' + document.referrer ]);
</script>

Google Analytics Reports

As you track errors as events using Google Analytics, you will find a list of them in your reports under “Event Tracking,” under the “Content” menu. Choose “Categories,” and then start drilling down through your error types.

You can save any of these graphs to your dashboard with the “Add to Dashboard” button at the top of each screen. I find it useful to list the top 404 errors on my dashboard, so that I can see whether anything new has popped up when I log in.

Google Analytics also lets you know of spikes in error messages. The “Intelligence” section allows you to set an alert for when a certain metric reaches a specified threshold. In my case, I want to know when the number of unique 404 errors has increased by more than 20% over the previous day.

In your custom alert, set the alert’s conditions to include “Event Action,” matching your error’s name exactly. In this case, the error name is “404.” Set it to alert you when the “Unique Events” percentage increases by more than 20% over the previous day. Be sure to check the box for the option to receive an email when this alert triggers!

Once you have captured enough data to analyze, start creating these dashboard widgets and alerts in Google Analytics, so that you can make informed decisions on how to improve your website.

How To Analyze Errors

Error messages will help you see in aggregate the most common stumbling blocks for users. Are a lot of users encountering errors with a particular text field? Perhaps the field for the expiration date of their credit card? Or for their email address? You might be surprised by what your users encounter.

Segmenting Data

If your website gets a lot of traffic, consider segmenting the user base to analyze the error messages. Look for groups of users who make up the majority of a certain kind of error event, because there may be something unique about that segment.

“New Visitors” are first-time visitors to your website. They are likely unfamiliar with the typical flow of your navigation and are brand new to your forms and so don’t know what fields are required. “Returning Visitors” will likely be familiar with your website, so they may not have a large impact on error rates (unless you’ve changed something that catches them by surprise).

To change the user segment that you’re looking at, go to your list of error events and click the drop-down menu next to “Advanced Segments.” By selecting “New Visitors” and then hitting “Apply,” the data will update to show only the errors that “New Visitors” have encountered.

Break down your data on error messages according to user segment in order to analyze the data more deeply.

Segmenting users by country can also give more context. I once wrestled with why so many users were triggering error messages for ZIP and postal codes in a form. After organizing the data by country, I saw a high number of errors from one country whose postal-code syntax I hadn’t accounted for in my form’s validation. I fixed the error and saw the error rate for ZIP and postal codes drop.

Check errors by country to see whether any patterns emerge in your error messages.

Referring sources for 404 pages is another way to examine the data. Use the “Filter Event Label” search bar to show errors whose referring source is a particular domain. Searching your own domain first is useful to see which incorrect URLs you can quickly fix on your own website.

Prioritize Issues

After segmenting the data, prioritize the errors that you want to fix. The top priority will be errors that affect a large group of people (i.e. ones that have a high number of unique events). Next, work on the errors that you know you can easily fix. You likely already know the cause of some errors (poor validation, unhelpful error message, etc.), so clean those up. For 404 errors, check which referring links come from your website, and fix those.

Examine 404 errors to see whether any particular referring links can be easily fixed.

Once you’ve cleaned up the errors that are easy to fix, track the new data for at least a week before doing another round of prioritization. Examine what has changed in the top errors and where they come from, and then research the cause of those errors.

Often, forms will need to be made more intuitive to help users avoid error messages. For example, if a lot of users are making mistakes when entering a date, then play with that field. Does your user base prefer drop-down menus for days, months and years? Do they make fewer errors if given a date picker? Are you giving them helpful examples of the syntax they need to follow? Track your changes and measure the rate of error events after each change to see what decreases user error.

Improve Your Error Messages

Improving the text, design and layout of your error messages could decrease the number of repeated errors by users. An error message might not be clear or might be hidden on the page; improve the user experience by testing changes to your error messages.

I prefer A/B testing to compare the effectiveness of error messages and their designs. On one form, I noticed that a number of users were skipping the phone-number field altogether, even though I’d indicated that it was required.

Some of the indicators of a required field that we tested.

After A/B testing different ways to indicate that the field was required and why it was required, we found that the combination of a link and a tooltip helped users recognize the need to fill in their phone number. This solution drastically decreased the rate of errors for this field.

On 404 pages, test out different content on users: link to your most popular pages; present a search form; try humorous content or Easter eggs to lighten the users’ spirits.

As you test different textual and design changes to your error messages, be sure to measure their effectiveness. Examine the following:

• Total error events, and total events per error message;


• Unique events per error message;


• Exit rates on pages with forms and 404 pages.

All of these rates should drop. Ideally, your users should find the website so intuitive that your error event data will represent only those who try to “beat the system.”

Conclusion

To sum up, track error messages and 404 pages as events in Google Analytics, and analyze the top error patterns. Prioritize the causes of errors, and continue to improve your forms and 404 pages to avoid errors altogether. Lastly, test changes in the content and design of error messages to see whether they decrease repeated errors. Improving your forms, 404 pages and error messages will improve your website’s overall user experience.

Additional Resources

• “Event Tracking Guide,” Google Analytics


• “A Primer on A/B Testing,” A List Apart


• “Optimizing Error Pages: Creating Opportunities Out of Mistakes,” Smashing Magazine


• “Web Form Validation: Best Practices and Examples,” Smashing Magazine

(al)

---

© Lara Swanson for Smashing Magazine, 2011.

Supporting Your Product: How To Provide Technical Support

Supporting Your Product: How To Provide Technical Support:

Whether your product is an open-source script, a Web application or a downloadable product, you will need to provide some form of technical support. This article explores the subject based on my experience of supporting our company’s product, Perch, a small content management system (CMS) that we sell as a download for people to install in their own hosting space. Our support has been a key factor in the success of this product, not just because users love responsive support, but because we have used what we have learned from users to improve the product.

Don’t Underestimate The Importance Of Support

As Eran Galperin says in “You’re Pricing It Wrong: Software Pricing Demystified” on Smashing Magazine:

“A commercial product that comes with support will often win over customers who want that assurance that someone will be on the other end of the line should they need it.”

Support can be a key selling point, a reason for a person to choose your product over the competition. In our case with Perch, the competition is often free software, so including unlimited support with a license is a big part of why someone might choose us over a competitor. Even for products aimed at technologically literate users, knowing that someone is on hand to answer questions or fix bugs can influence the decision to buy or sign up.

Don’t Underestimate The Time This Will Take

Users will always need support. You could have a bulletproof product and the most excellent tutorials and documentation, and someone will find a way to break it or just not read the information staring them in the face. Later in this article, I’ll explain some ways to minimize support requests and the time spent in dealing with them. But you should expect to offer support and build it into the price of your product.

Your support systems should also help you track the amount of time being taken up by support, so that you can plan for future requirements. If you are a small company whose product developers are supporting the product at present, knowing the amount of time each license or user requires for support on average will enable you to project when you might need to hire additional support staff.

Methods Of Providing Technical Support

When launching your product, decide how you will support it. Depending on the product and the people using it, you might offer some or all of the following types of support:

• Phone,


• Email,


• Social media,


• Ticketing system,


• Real-time chat.

Phone

Supporting users by phone is time-consuming, but for some types of products, it can reassure potential buyers, particularly if they are not Internet-savvy or if the product handles sensitive information (for example, financial or health data). Users might trust the product more if they know they can speak to a real person. You can take phone support further by offering a remote-desktop feature to help customers right on their computer.

We chose not to offer phone support at Perch, because the support requests we get generally require us to look at a customer’s config file, diagnostic report or template code. So, an initial phone conversation would simply raise the cost of supporting customers, because we’d have to ask them to send this information by email or some other way.

If you do provide phone support, clearly state when it is available, including time-zone information. Also, keep track of the time you spend on this and the issues that customers raise so that you can combine it with the information that you collect via email or your online help desk.

Image source: Opensourceway.

Email

A lot of companies start with email support. Simply publish an email address, and answer queries as they come in. The advantages are that you don’t need any additional software, and everyone uses email. However, it gets tricky if you are not the only person supporting the product. If all of the support staff logs into the same mailbox, two people could very easily answer the same query, or a request could get ignored because everyone thinks someone else is dealing with it.

Email is also less than ideal for tracking requests over time and for working out the amount of time you spend dealing with them. You also need to be quite disciplined at filing away “closed” requests before your inbox descends into chaos.

If email is your predominant support mechanism, then consider setting up template responses to common requests, much as you would use canned responses in a help desk system (as I’ll describe below). Don’t forget to keep improving, adding to and correcting these responses as your website or product changes. Inadvertently giving out old advice is easy when these templates get out of date.

Social Media

Support via social media has become so important that many large companies are far more responsive on Twitter than via traditional means. Social media should be a part of your support system, but it shouldn’t be the only way that you help people. Being able to quickly respond to someone who is having a problem or has a question about your product is incredibly powerful. We have set up searches in our Twitter clients, so as soon as someone mentions Perch, we can respond. If a person mentions that they are trying out our demo, we simply say, “Let us know if you have any questions!” and we leave it at that. It is important that you not appear to hound potential customers; just give them a way to ask informally about anything on their mind.

If you have staff dedicated to support on Twitter, make sure they are empowered to help people. Many large companies have dedicated Twitter support personnel who only seem able to direct people to answers on the company website, which is often more frustrating than helpful! T-Mobile in the UK handles Twitter support very well via its @TMobileUKhelp account. Its support personnel is able to deal with most of the things that the phone-support operators handle, once the customer has verified their identity via direct message.

Small companies can do social media really well, often better than large companies. If a customer is using Twitter to vent their frustration, a couple of quick and helpful messages can turn them from “I’m so annoyed” to “Wow! Support for this product is amazing!” People are generally very understanding about problems as long as they can get help quickly.

A lot of support requests are hard to deal with on Twitter, though. For example, at Perch, many questions require us to see the user’s code or to ask them to try something. In these cases, you need to be able to direct them to another channel, whether a ticketing system or even an email address. Long discussions over Twitter tend not to be very helpful; so, unless I can answer the query in one or two messages, I point the user to our ticketing system or forum, where I can pick up the conversation and provide better information.

Ticketing System

I would suggest that anyone with a commercial product use some kind of ticketing system. This support system can often be combined with the methods listed above. For example, many systems can turn incoming emails into tickets, or can log phone sessions in a useful format, or have an interface where users can submit tickets directly.

Ticketing systems make the process of providing support easier when multiple staff members are involved, because you can see whether a request is being responded to and who is working on it. They also make it far easier to keep track of the support requests coming in and how much time they are taking up.

To use a real-world case study, when we launched Perch just over two years ago, we started using a hosted software-as-a-service system called Tender. Tender is a fairly lightweight system that allows users to submit tickets that are either public (visible and answerable by anyone, not just support staff) or private (visible only to support staff).

We were happy with Tender, except for a couple of issues. First, we didn’t want our ticketing system to function as a forum, so we set up a separate forum elsewhere. But this meant that people had to look in two places for answers: the forum and the ticketing system. Our documentation was also located elsewhere. Secondly, because anyone could view and respond to support queries, we often saw customers themselves replying to tickets submitted by other customers; often the advice was helpful, but sometimes it was incorrect or confusing, and customers couldn’t tell the difference between official responses and responses from well-meaning customers. There wasn’t a way to stop this from happening other than to make all tickets private.

It became obvious that Tender, while a good system, just didn’t suit the model we wanted to use for support. This, it turns out, is key when selecting a support system — far more important than the feature list. When looking for a support system, decide first how you want to support your customers, then assess each system against that model to see whether it fits.

Having decided that our initial choice of Tender wasn’t quite working out, we made a list of what we wanted in a support system:

1. A system with tickets and public forums all in one place (plus, the ability to publish documentation on the same system would be ideal);


2. Excellent support for multiple people responding to issues;


3. A system that can handle HTML and code examples being posted by customers and by us as responses;


4. Statistics to enable us to track tickets, response times and so on.

We started to research, and we asked on Twitter which support systems people liked. Zendesk quickly rose to the top of the list, and were it not for a long-standing issue with code formatting, we would probably have used Zendesk. I really liked the integration of social media in the product; however, while this was a nice to have, the problem with the code snippets was a deal-breaker.

We then looked at Assistly. It is another feature-rich system, but it felt a little too oriented around email and self-service for what we wanted. It felt a little impersonal in some ways, and our decision came down to it just not fitting our model and how we wanted Perch support to look and feel.

Finally we were pointed to HelpSpot. HelpSpot doesn’t have as many features “on paper” as the other two systems we looked at, but, crucially, it supports the combination of forums, tickets and documentation that we were looking for, thus enabling us to support customers the way we wanted. After trialling version 3 of the product, which was still in beta, we decided to move our tickets, forums and documentation to a self-hosted installation of HelpSpot.

All of the systems we looked at are good systems with excellent features. Ultimately, it came down to which best suited our model for providing support. Having figured that out before testing the systems in trial, we were able to choose more easily between them, and we are still happy with our choice a few months after having made the switch.

Real-Time Chat

Real-time chat-based support is a feature of some ticketing systems, and is also available as a standalone service (as with Olark). We do use this with Perch, although primarily for pre-sales queries rather than for actual support. Like Twitter, it can be a really good way to quickly answer a question, but for longer answers and code samples, dealing with people in the main support area is much easier.

Real-time support on websites can be helpful for companies that offer a service. With Olark, you can see exactly where someone is on your website as you are talking to them, so guiding someone through a potentially confusing process would be simple. It does, however, require that someone be available to provide this support should users come to rely on it. With a ticketing system, people expect some delay in getting a reply.

How To Reduce Support Requests And Time Spent Dealing With Them

You will never eliminate support requests completely, but you can do a lot to minimize them and to reduce the time you take in dealing with them.

Design Support Requests Out of Your Product

With Perch, we actively try to see support requests as an indication that something needs improvement or clarification in the product or related support material. By tracking requests and seeing where patterns emerge that show people running into problems in certain places, we are able to prevent the problem from occurring or provide better support material.

For example, before logging into your Perch admin account on your own website, you need to go to your account on the Perch website and specify the domain where Perch is installed. You can actually set two domains — the live and test ones — but before you can use Perch, you need to set at least one of these.

In the past, if you hadn’t set a domain in your account, then when logging in you got a message saying, “Sorry, your license key isn’t valid for this domain.”

People who didn’t fully read their email invoice might have missed the bit about setting up domains and so would have been confused when they saw this message, and thus submitted a support ticket. In an update to Perch, we changed this process so that if an administrator hadn’t yet entered any content, we could detect that they were a new user who just needed to configure their domains and so prompted them to do so (giving them the domain that they needed to register in their account). Support tickets were no longer submitted for this issue.

Designing support requests out of the product as much as possible obviously benefits us, because the less support we need to provide per license, the more profitable our product is. But it also gives our customers a better first experience with Perch. Being confused and needing support before even logging in isn’t a great first impression.

Build Debugging or Diagnostic Information Into the Product

Perch is a product that people download and install in their own hosting space. As you can imagine, we are now experts in the many bizarre ways that shared hosting providers configure PHP! We needed a way to get information from not very technical users about the environment in which they were running Perch. To do this, we created a diagnostics report that gives us a lot of information about the server that Perch is running on, which apps are installed, what their path to Perch is, and so on. The report, coupled with the user’s query, often gives us enough information to answer the support request right away.

Building in some diagnostic information that users can find and send to you could save a lot of back and forth, especially if your product or app is self-hosted and can be deployed in a variety of systems.

Add Features to the Product

If many of the people requesting support are asking about how to do something that your product doesn’t currently do, then it would be worth thinking about how you might accommodate this as a feature. While your ideas about what your product is and is not might be pretty fixed, you need to have some flexibility. In our case, Perch is “a really little CMS,” designed for small websites. When we launched, we thought that people wouldn’t need features such as undo, create drafts, edit drafts and previewing. It soon became apparent through support that our users very much wanted these features, and so we found a way to add them without bloating the software. Use your support requests to help guide development. Once it becomes obvious that someone is asking for something that Perch doesn’t do, we will often ask them, “How do you see this working?”

Provide a Range of Support Material

People learn how to use apps in a variety of ways. I like to read documentation and play around with code. For many people — especially visual learners — actually seeing things happen is much more helpful.

We were getting support requests from people who were obviously confused by our documentation. But we also heard people say how good our documentation was! What was going on? Blaming the first group for not understanding the documentation would be tempting — but once you decide to blame the user, you miss an opportunity to help people in different ways.

To help visual learners, we started a series of video tutorials. Currently, these videos just deal with the basics of using the product, but they have made a huge difference to the number of people we have to handhold through the website-building process. Frequently, we will point someone to the tutorial and then not hear from them again until we see the first post on their newly launched website. In the past, we might have seen a number of tickets from them during that process. The lesson here is to provide material in different formats and for different levels of users: bare documentation is important for technical users and for those who like to read quickly and get on with it; step-by-step examples and videos will help others.

Use a Support System That Lets You Create Template Answers

Often we need to ask people who request support for additional information, such as the diagnostics report mentioned above. HelpSpot lets us store these answers and punch them in as responses in one click, saving us time on the initial interaction. If you can reduce the time spent saying the same things, then you will have more time to dedicate to solving problems and working on the product.

Image source: Opensourceway.

How to Phase Out Support for Old Versions of a Product

If you sell desktop, phone or self-hosted Web software, rather than software as a service, you might need to consider what to do about supporting old versions of your product?

Traditional software companies tend to give users sufficient warning that support for an old product will end on a particular date. Security patches are often made available past that date if flaws are found in the old product, but no other fixes or changes are made. For example, Microsoft’s mainstream support for Windows XP Professional ended in 2009, although “Extended” support (which includes security patches) will continue until 2014.

The most important thing is to be fair to customers and give them plenty of notice of the end of a product version’s life. Your company needs to make decisions about the status of old versions far in advance of doing anything about it, and let customers know when support for an old version might end or be limited to critical security issues.

Some Final Thoughts

A question we are often asked at Perch is, “Is the support a nightmare?” It is all too easy for software developers to view support as a necessary evil, a part of the job to deal with as quickly as possible or even to outsource. If you approach support in this way, then you are missing out on a chance to make a real difference with people. You are also missing out on product improvements that you could have made by listening carefully to customer requests.

I firmly believe that software developers should provide their own support — perhaps not all of the support, if the product is popular or gets a lot of non-technical requests on the front line, but certainly some of it. It’s only by seeing the pain points firsthand and helping users through them that you can start figuring out how to solve them — and solving problems should be what we software developers do best.

Further Reading

• “Seven Steps to Remarkable Customer Service,” Joel on Software


• “On Scaling Customer Service in a Startup,” David Noel


• “How to Use Twitter for Customer Service,” Mashable

(al)

---

© Rachel Andrew for Smashing Magazine, 2011.

Cómo instalar aplicaciones Android en Windows fácilmente

Cómo instalar aplicaciones Android en Windows fácilmente:

Las plataformas móviles están adquiriendo cada vez más importancia hasta el punto de que es mucho más fácil encontrar utilidades concretas en estos entornos que en los de escritorio gracias a sus tiendas de aplicaciones. La posibilidad de portar las apps móviles al escritorio es una idea que muchos apreciarían, pues supone no modificar hábitos al entrar en casa desde la calle o al utilizar los mismos desarrollos y entornos en ambos mundos. Y esto último es posible gracias a BlueStacks App Player.

BlueStacks App Player es una herramienta para Windows 7 que permite ejecutar aplicaciones de Android. Se encuentra en fase inicial de desarrollo alpha y es totalmente gratuita, versión Pro con capacidades especiales llegará más adelante. La tecnología necesaria para que este ingenio funcione ha estado capitaneada por el ex CTO de McAfee y miembro directivo de Cloud.com Rosen Sharma. Su desarrollo ha tomado a 10 ingenieros dos años en total, pues han querido hacer las cosas bien desde un principio utilizando un método de virtualización que posibilita la ejecución de estas aplicaciones en modo de pantalla completa sin que eso perjudique a la usabilidad o a la resolución gráfica. Por ejemplo, las apps de Angry Birds o Fuit Ninja se visualizan a gran tamaño.

Nada más descargar el reproductor y ejecutarlo veremos que tenemos a nuestra disposición 10 aplicaciones pre-cargadas como Bloomberg, LivingSocial, Huffington Post y Creative Mobile y tenemos disponibles otras 26 para instalar desde la nube que irán aumentando conforme se siga trabajando con más desarrolladores de apps móviles que quieran sumarse al proyecto. Además hay una interesante funcionalidad en este widget y es la posibilidad de pasar aplicaciones desde nuestro teléfono al escritorio gracias a Cloud Connect, de ese modo no tendremos que volver a pagar por aplicaciones que ya hemos comprado para nuestro smartphone Android.

Estoy convencido de que propuestas como estas van a pegar muy fuerte en el futuro a medida que nos damos cuenta de que el rendimiento de las aplicaciones móviles tienen poco que envidiar a las de escritorio. En BlueStacks ya están trabajando en su adaptación para Mac y esperan alcanzar el millón de descargas en poco tiempo.

Content Marketing Challenge: How to Use your Resources Effectively

Content Marketing Challenge: How to Use your Resources Effectively:

Time and time again, the challenge of a lack of resources gets in the way of an organization creating great content marketing.

I hear these two questions all the time:

1. What is the right team structure?
2. How do I get my coworkers or employees on board to participate?

In this post I will provide a few different solutions so that you know how to use your resources more effectively when it comes to content marketing.

Photo from AA Resources

First off, let’s talk about team structure.

Many startup and expansion stage companies have small marketing teams and they are trying to figure out how best to structure the team in order to work most effectively. I know this is a common issue for many companies because when we were planning this week’s Content Marketing Workshop with OpenView Senior Advisor Joe Pulizzi and CMI Lead Strategist Robert Rose the question came up several times. In their new book Managing Content Marketing (and in our workshop), Joe and Robert provide a team structure that they have seen work well in other organizations.  Here are the roles at a high level:  (Check out the book for details on the structure, including job descriptions).

• Chief Content Officer or Manager – responsible for ensuring perfection in everything related to content marketing
• Managing Editors – responsible for the “day-to-day execution” against the content marketing program
• Content Creators – responsible for producing the content
• Content Producers – responsible for designing the final content products
• Chief Listening Officer – responsible for listening across all content and social media channels

Now, let’s talk about getting employees on board to participate.

Let’s face it, there comes a time when even the most dedicated content creators within your organization will fail to meet their commitments. It may be because other goals or commitments take priority over content creation. If you have been executing against a content marketing strategy for a few months, I have no doubts that you have had challenges getting people to blog or create other content. I say this with 100 percent certainty because we haven’t figured out how to completely remove this issue at OpenView! I have written about it a few times before (How to Get Everyone on Board with Content Marketing and More Answers to your Top Content Marketing Challenges), so here are a few more ideas we have tested or are considering:

• Set real expectations and explain consequences: I have blogged about the importance of senior management explaining the value of the blogging program before, so this isn’t a new idea entirely. In addition to explaining the value, ensure that management explains exactly what is required and exactly what is at stake. For example, each employee is required to write two blog posts per month and in order to receive 15 percent of their bonus, each employee is required to meet that commitment at 100 percent. Anything less results in a smaller bonus.
• Share ideas or themes to get the creative juices flowing: Often times, I hear that people just don’t know what to write about. They say that they are excited about blogging, but have no idea what story they want to share. It is really simple to get rid of this problem, especially in the short term. The CCO (or main content manager) should have a constant backlog of topics for blog posts, articles, ebooks, etc. as part of an overall editorial calendar.  It should be up to him or her to sit down with every willing blogger to share ideas and empower new bloggers to write consistently. If you don’t have a robust editorial calendar, execute some keyword research to begin to identify topics that your target audience is interested in. A few ideas for blog posts are bound to come from that!
• Determine when it makes sense to get help – While tapping into your coworkers for content is the most economical way to create content (not accounting for lost time while they are creating content), it isn’t always that easy to get people on board. Sometimes your coworkers/employees are just too busy with their day-to-day responsibilities! In this case, evaluate whether or not it is essential to have that person actively contribute. If it doesn’t, consider outsourcing the content creation to a freelancer, content platforms (such as Contently), or hire a capable intern to ghostwrite blog posts. Schedule regular meetings between the employee and the ghostwriter to share ideas and talk through blog posts. Who knows, you may find a valuable asset on your team who isn’t comfortable with writing, but excels with this model!

What do you think?  How have you overcome resource challenges within your content marketing program?

You may also like:

• 6 Tips to Solve your Top Content Marketing Challenges
• Expansion Stage CEOs: Understand the Power of 3!
• 5 Things that Predict Success in Software Companies
• Looking To Grow Your Company? Avoid These 3 Landmines
• Reinventing Board Meetings
• Even startups need a COO
• Is Your Software Product Social?
• 10 Content Marketing Lessons from Anthony Weiner
• Is your Expansion Stage Company Missing its Reproductive Organs?

Puede que Nike+ haya salvado mi vida.

Aun no lo se. Esa problemática cuestión de la prestidigitacion hace imposible saber si realmente uno realmente iba a abandonar este mundo a manos de un problema cardíaco hasta que le toca. Pero si para cuando te toca tu corazón viene preparado entonces es mejor prevenir. Asi que haciendo conclusiones sobre mi genética y mi propensión a engordar fácilmente, con dulces, muchos dulces, y harinas, pah; decidí que tendría una buena red de seguridad para cuando el bombo fallase y al mismo tiempo no tener que abandonar el eventual cucharazo de dulce de leche. Esto potenciado por dos historias coetáneas que confirmaban la teoría de que mas vale ser un atleta. Empece por buscar un zapato que fuera de suela fina (no apoyar el talón antes), me había hecho pelota las rodillas corriendo con zapatos altos y esta vez fui por unos económicos Pegasus. Bien, al principio duele recuperarse de una década de sedentarismo, y prepararse para los próximos 10, pero vale la pena intentarlo. La endorfina es adictiva creo. Es lo que te hace ir y comprar un champion como el Vomero, y salir a despertar el esqueleto. Para motivarse a correr para mi fue esencial el apoyo de Nike+ y de RunKeeper al principio, que permitieron auto motivarme. Les doy un tip a los que no corren con zapatos Nike+ compatibles, el chip, lo pones en la lengüeta, y el Sportsband hace un lindo reloj, no sale nada comparado con la cuenta del Hospital. Si te das manija solo bien, pero si sos de pisartelas como yo, entonces vale la pena. Ahora ya hay un Sportsband con GPS para subir la ruta directamente a Nike+. El nombre de la misión es "Caminando a los 90". Vamos arriba que podemos, ahora en verano es una papa salir a la rambla y sudar. A no romperse las rodillas, pasar del Pegasus al Pegasus+ es bueno, pero si vas por asfalto el Vomero 6+ es como fisioterapia, mezclar zapatos funciona para que el pie no se adapte a uno solo, y siempre es bueno descansar tanto el zapato como la rodilla. En MVD, Vomero $3200 Pegasus $1490, Pegasus+ $1890, Sportsband + Sensor $2000