Agregador de noticias

A Pandora for relationship management. That’s how Nimble describes version 3.0 of its social relationship manager platform, because of a Rules Engine that curates engagement opportunities, birthdays, job changes and “people of importance.” Sort of like setting up a station on Pandora, but built around people you want to stay in contact with.

Read full story...
Follow us on Twitter Join free newsletter View upcoming events Find a new job

South Korean mega-vendor Samsung keeps churning out the devices to cover every conceivable base and user need, with the new Mega 6.3" screen phablet joining a waterproof S4 model, with an S4 mini confirmed on the way. 

Read full story...
Follow us on Twitter Join free newsletter View upcoming events Find a new job

Los ordenadores portátiles con pantallas táctiles han llegado para quedarse, aunque a muchos, entre los que se encuentra Apple, no les parezca una solución ideal, la realidad es que en el mercado están funcionando. Las ventas en el primer trimestre de año han sido de 4,57 millones de unidades, según Displaybank (IHS).

El crecimiento con respecto al trimestre anterior es de un 51,8%, y prácticamente representan el 10% de las ventas de todo tipo de portátiles, que se estima en unas 46 millones de unidades.

Hay que tener en cuenta que el mercado de portátiles táctiles se ha visto potenciado por Windows 8 y los principales fabricantes, pero realmente estamos en un estado inicial (siete meses desde la aparición del nuevo Windows), por lo que la tendencia es que vaya creciendo hasta que se igualen con los ordenadores sin pantalla táctil. Va a depender mucho de la oferta que hagan los fabricantes, lo que nos quieran vender.

El mercado de los ordenadores en general ha caído, según IDC un 13,9% en este trimestre que hemos dejado atrás. Dentro de lo negativo, este tipo de portátiles traen poco de luz a la situación. De hecho nombres como ASUS o Lenovo tienen la intención de duplicar la penetración de portátiles táctiles a medio plazo.

Paul Otellini, hasta hace días CEO de Intel, ya desveló los planes de su compañía con respecto a dispositivos táctiles con Windows 8: los quería cercanos a los 200 dólares, y no muy lejos de finales de 2013.

Vía | Digitimes | TOM’s Hardware

Great design is a product of care and attention applied to areas that matter, resulting in a useful, understandable, and hopefully beautiful user interface. But don’t be fooled into thinking that design is left only for designers.

There is a lot of design in code, and I don’t mean code that builds the user interface—I mean the design of code.

Well-designed code is much easier to maintain, optimize, and extend, making for more efficient developers. That means more focus and energy can be spent on building great things, which makes everyone happy—users, developers, and stakeholders.

There are three high-level, language-agnostic aspects to code design that are particularly important.

1. System architecture—The basic layout of the codebase. Rules that govern how various components, such as models, views, and controllers, interact with each other.
2. Maintainability—How well can the code be improved and extended?
3. Reusability—How reusable are the application’s components? How easily can each implementation of a component be customized?

In looser languages, specifically JavaScript, it takes a bit of discipline to write well-designed code. The JavaScript environment is so forgiving that it’s easy to throw bits and pieces everywhere and still have things work. Establishing system architecture early (and sticking to it!) provides constraints to your codebase, ensuring consistency throughout.

One approach I’m fond of consists of a tried-and-true software design pattern, the module pattern, whose extensible structure lends itself to a solid system architecture and a maintainable codebase. I like building modules within a jQuery plugin, which makes for beautiful reusability, provides robust options, and exposes a well-crafted API.

Below, I’ll walk through how to craft your code into well-organized components that can be reused in projects to come.

The module pattern

There are a lot of design patterns out there, and equally as many resources on them. Addy Osmani wrote an amazing (free!) book on design patterns in JavaScript, which I highly recommend to developers of all levels.

The module pattern is a simple structural foundation that can help keep your code clean and organized. A “module” is just a standard object literal containing methods and properties, and that simplicity is the best thing about this pattern: even someone unfamiliar with traditional software design patterns would be able to look at the code and instantly understand how it works.

In applications that use this pattern, each component gets its own distinct module. For example, to build autocomplete functionality, you’d create a module for the textfield and a module for the results list. These two modules would work together, but the textfield code wouldn’t touch the results list code, and vice versa.

That decoupling of components is why the module pattern is great for building solid system architecture. Relationships within the application are well-defined; anything related to the textfield is managed by the textfield module, not strewn throughout the codebase—resulting in clear code.

Another benefit of module-based organization is that it is inherently maintainable. Modules can be improved and optimized independently without affecting any other part of the application.

I used the module pattern for the basic structure of jPanelMenu, the jQuery plugin I built for off-canvas menu systems. I’ll use that as an example to illustrate the process of building a module.

Building a module

To begin, I define three methods and a property that are used to manage the interactions of the menu system.

var jpm = { animated: true, openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } };

The idea is to break down code into the smallest, most reusable bits possible. I could have written just one toggleMenu( ) method, but creating distinct openMenu( ) and closeMenu( ) methods provides more control and reusability within the module.

Notice that calls to module methods and properties from within the module itself (such as the calls to setMenuStyle( )) are prefixed with the this keyword—that’s how modules access their own members.

That’s the basic structure of a module. You can continue to add methods and properties as needed, but it doesn’t get any more complex than that. After the structural foundations are in place, the reusability layer—options and an exposed API—can be built on top.

jQuery plugins

The third aspect of well-designed code is probably the most crucial: reusability. This section comes with a caveat. While there are obviously ways to build and implement reusable components in raw JavaScript (we’re about 90 percent of the way there with our module above), I prefer to build jQuery plugins for more complex things, for a few reasons.

Most importantly, it’s a form of unobtrusive communication. If you used jQuery to build a component, you should make that obvious to those implementing it. Building the component as a jQuery plugin is a great way to say that jQuery is required.

In addition, the implementation code will be consistent with the rest of the jQuery-based project code. That’s good for aesthetic reasons, but it also means (to an extent) that developers can predict how to interact with the plugin without too much research. Just one more way to build a better developer interface.

Before you begin building a jQuery plugin, ensure that the plugin does not conflict with other JavaScript libraries using the $ notation. That’s a lot simpler than it sounds—just wrap your plugin code like so:

(function($) { // jQuery plugin code here })(jQuery);

Next, we set up our plugin and drop our previously built module code inside. A plugin is just a method defined on the jQuery ($) object.

(function($) { $.jPanelMenu = function( ) { var jpm = { animated: true, openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; }; })(jQuery);

All it takes to use the plugin is a call to the function you just created.

var jpm = $.jPanelMenu( ); Options

Options are essential to any truly reusable plugin because they allow for customizations to each implementation. Every project brings with it a slew of design styles, interaction types, and content structures. Customizable options help ensure that you can adapt the plugin to fit within those project constraints.

It’s best practice to provide good default values for your options. The easiest way to do that is to use jQuery’s $.extend( ) method, which accepts (at least) two arguments.

As the first argument of $.extend( ), define an object with all available options and their default values. As the second argument, pass through the passed-in options. This will merge the two objects, overriding the defaults with any passed-in options.

(function($) { $.jPanelMenu = function(options) { var jpm = { options: $.extend({ 'animated': true, 'duration': 500, 'direction': 'left' }, options), openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; }; })(jQuery);

Beyond providing good defaults, options become almost self-documenting—someone can look at the code and see all of the available options immediately.

Expose as many options as is feasible. The customization will help in future implementations, and flexibility never hurts.

API

Options are terrific ways to customize how a plugin works. An API, on the other hand, enables extensions to the plugin’s functionality by exposing methods and properties for the implementation code to take advantage of.

While it’s great to expose as much as possible through an API, the outside world shouldn’t have access to all internal methods and properties. Ideally, you should expose only the elements that will be used.

In our example, the exposed API should include calls to open and close the menu, but nothing else. The internal setMenuStyle( ) method runs when the menu opens and closes, but the public doesn’t need access to it.

To expose an API, return an object with any desired methods and properties at the end of the plugin code. You can even map returned methods and properties to those within the module code—this is where the beautiful organization of the module pattern really shines.

(function($) { $.jPanelMenu = function(options) { var jpm = { options: $.extend({ 'animated': true, 'duration': 500, 'direction': 'left' }, options), openMenu: function( ) { … this.setMenuStyle( ); }, closeMenu: function( ) { … this.setMenuStyle( ); }, setMenuStyle: function( ) { … } }; return { open: jpm.openMenu, close: jpm.closeMenu, someComplexMethod: function( ) { … } }; }; })(jQuery);

API methods and properties will be available through the object returned from the plugin initialization.

var jpm = $.jPanelMenu({ duration: 1000, … }); jpm.open( ); Polishing developer interfaces

With just a few simple constructs and guidelines, we’ve built ourselves a reusable, extensible plugin that will help make our lives easier. Like any part of what we do, experiment with this structure to see if it works for you, your team, and your workflow.

Whenever I find myself building something with a potential for reuse, I break it out into a module-based jQuery plugin. The best part about this approach is that it forces you to use—and test—the code you write. By using something as you build it, you’ll quickly identify strengths, discover shortcomings, and plan changes.

This process leads to battle-tested code ready for open-source contributions, or to be sold and distributed. I’ve released my (mostly) polished plugins as open-source projects on GitHub.

Even if you aren’t building something to be released in the wild, it’s still important to think about the design of your code. Your future self will thank you.

We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.

As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.

Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual units of functionality are behaving as expected.

That’s where unit testing comes in. And we’ll have a very hard time writing unit tests until we start writing testable JavaScript.

Unit vs. integration: what’s the difference?

Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts with our app, and what the user should expect to see as she does. Selenium is a popular tool for automating browsers. Capybara for Ruby makes it easy to talk to Selenium, and there are plenty of tools for other languages, too.

Here’s an integration test for a portion of a search app:

def test_search fill_in('q', :with => 'cat') find('.btn').click assert( find('#results li').has_content?('cat'), 'Search results are shown' ) assert( page.has_no_selector?('#results li.no-results'), 'No results is not shown' ) end

Whereas an integration test is interested in a user’s interaction with an app, a unit test is narrowly focused on a small piece of code:

When I call a function with a certain input, do I receive the expected output?

Apps that are written in a traditional procedural style can be very difficult to unit test—and difficult to maintain, debug, and extend, too. But if we write our code with our future unit testing needs in mind, we will not only find that writing the tests becomes more straightforward than we might have expected, but also that we’ll simply write better code, too.

To see what I’m talking about, let’s take a look at a simple search app:

When a user enters a search term, the app sends an XHR to the server for the corresponding data. When the server responds with the data, formatted as JSON, the app takes that data and displays it on the page, using client-side templating. A user can click on a search result to indicate that he “likes” it; when this happens, the name of the person he liked is added to the “Liked” list on the right-hand side.

A “traditional” JavaScript implementation of this app might look like this:

var tmplCache = {}; function loadTemplate (name) { if (!tmplCache[name]) { tmplCache[name] = $.get('/templates/' + name); } return tmplCache[name]; } $(function () { var resultsList = $('#results'); var liked = $('#liked'); var pending = false; $('#searchForm').on('submit', function (e) { e.preventDefault(); if (pending) { return; } var form = $(this); var query = $.trim( form.find('input[name="q"]').val() ); if (!query) { return; } pending = true; $.ajax('/data/search.json', { data : { q: query }, dataType : 'json', success : function (data) { loadTemplate('people-detailed.tmpl').then(function (t) { var tmpl = _.template(t); resultsList.html( tmpl({ people : data.results }) ); pending = false; }); } }); $('<li>', { 'class' : 'pending', html : 'Searching &hellip;' }).appendTo( resultsList.empty() ); }); resultsList.on('click', '.like', function (e) { e.preventDefault(); var name = $(this).closest('li').find('h2').text(); liked.find('.no-results').remove(); $('<li>', { text: name }).appendTo(liked); }); });

My friend Adam Sontag calls this Choose Your Own Adventure code—on any given line, we might be dealing with presentation, or data, or user interaction, or application state. Who knows! It’s easy enough to write integration tests for this kind of code, but it’s hard to test individual units of functionality.

What makes it hard? Four things:

• A general lack of structure; almost everything happens in a $(document).ready() callback, and then in anonymous functions that can’t be tested because they aren’t exposed.
• Complex functions; if a function is more than 10 lines, like the submit handler, it’s highly likely that it’s doing too much.
• Hidden or shared state; for example, since pending is in a closure, there’s no way to test whether the pending state is set correctly.
• Tight coupling; for example, a $.ajax success handler shouldn’t need direct access to the DOM.

Organizing our code

The first step toward solving this is to take a less tangled approach to our code, breaking it up into a few different areas of responsibility:

• Presentation and interaction
• Data management and persistence
• Overall application state
• Setup and glue code to make the pieces work together

In the “traditional” implementation shown above, these four categories are intermingled—on one line we’re dealing with presentation, and two lines later we might be communicating with the server.

While we can absolutely write integration tests for this code—and we should!—writing unit tests for it is pretty difficult. In our functional tests, we can make assertions such as “when a user searches for something, she should see the appropriate results,” but we can’t get much more specific. If something goes wrong, we’ll have to track down exactly where it went wrong, and our functional tests won’t help much with that.

If we rethink how we write our code, though, we can write unit tests that will give us better insight into where things went wrong, and also help us end up with code that’s easier to reuse, maintain, and extend.

Our new code will follow a few guiding principles:

• Represent each distinct piece of behavior as a separate object that falls into one of the four areas of responsibility and doesn’t need to know about other objects. This will help us avoid creating tangled code.
• Support configurability, rather than hard-coding things. This will prevent us from replicating our entire HTML environment in order to write our tests.
• Keep our objects’ methods simple and brief. This will help us keep our tests simple and our code easy to read.
• Use constructor functions to create instances of objects. This will make it possible to create “clean” copies of each piece of code for the sake of testing.

To start with, we need to figure out how we’ll break our application into different pieces. We’ll have three pieces dedicated to presentation and interaction: the Search Form, the Search Results, and the Likes Box.

We’ll also have a piece dedicated to fetching data from the server and a piece dedicated to gluing everything together.

Let’s start by looking at one of the simplest pieces of our application: the Likes Box. In the original version of the app, this code was responsible for updating the Likes Box:

var liked = $('#liked');
 var resultsList = $('#results');
 
 // ... 

 resultsList.on('click', '.like', function (e) { e.preventDefault();
 var name = $(this).closest('li').find('h2').text();
 liked.find( '.no-results' ).remove();
 $('<li>', { text: name }).appendTo(liked);
 });

The Search Results piece is completely intertwined with the Likes Box piece and needs to know a lot about its markup. A much better and more testable approach would be to create a Likes Box object that’s responsible for manipulating the DOM related to the Likes Box:

var Likes = function (el) { this.el = $(el); return this; }; Likes.prototype.add = function (name) { this.el.find('.no-results').remove(); $('<li>', { text: name }).appendTo(this.el); };

This code provides a constructor function that creates a new instance of a Likes Box. The instance that’s created has an .add() method, which we can use to add new results. We can write a couple of tests to prove that it works:

var ul; setup(function(){ ul = $('<ul><li class="no-results"></li></ul>'); }); test('constructor', function () { var l = new Likes(ul); assert(l); }); test('adding a name', function () { var l = new Likes(ul); l.add('Brendan Eich'); assert.equal(ul.find('li').length, 1); assert.equal(ul.find('li').first().html(), 'Brendan Eich'); assert.equal(ul.find('li.no-results').length, 0); });

Not so hard, is it? Here we’re using Mocha as the test framework, and Chai as the assertion library. Mocha provides the test and setup functions; Chai provides assert. There are plenty of other test frameworks and assertion libraries to choose from, but for the sake of an introduction, I find these two work well. You should find the one that works best for you and your project—aside from Mocha, QUnit is popular, and Intern is a new framework that shows a lot of promise.

Our test code starts out by creating an element that we’ll use as the container for our Likes Box. Then, it runs two tests: one is a sanity check to make sure we can make a Likes Box; the other is a test to ensure that our .add() method has the desired effect. With these tests in place, we can safely refactor the code for our Likes Box, and be confident that we’ll know if we break anything.

Our new application code can now look like this:

var liked = new Likes('#liked'); var resultsList = $('#results');
 
 // ... 

 resultsList.on('click', '.like', function (e) { e.preventDefault();
 var name = $(this).closest('li').find('h2').text();
 liked.add(name); });

The Search Results piece is more complex than the Likes Box, but let’s take a stab at refactoring that, too. Just as we created an .add() method on the Likes Box, we also want to create methods for interacting with the Search Results. We’ll want a way to add new results, as well as a way to “broadcast” to the rest of the app when things happen within the Search Results—for example, when someone likes a result.

var SearchResults = function (el) { this.el = $(el); this.el.on( 'click', '.btn.like', _.bind(this._handleClick, this) ); }; SearchResults.prototype.setResults = function (results) { var templateRequest = $.get('people-detailed.tmpl'); templateRequest.then( _.bind(this._populate, this, results) ); }; SearchResults.prototype._handleClick = function (evt) { var name = $(evt.target).closest('li.result').attr('data-name'); $(document).trigger('like', [ name ]); }; SearchResults.prototype._populate = function (results, tmpl) { var html = _.template(tmpl, { people: results }); this.el.html(html); };

Now, our old app code for managing the interaction between Search Results and the Likes Box could look like this:

var liked = new Likes('#liked'); var resultsList = new SearchResults('#results');
 
 // ... 

 $(document).on('like', function (evt, name) { liked.add(name); })

It’s much simpler and less entangled, because we’re using the document as a global message bus, and passing messages through it so individual components don’t need to know about each other. (Note that in a real app, we’d use something like Backbone or the RSVP library to manage events. We’re just triggering on document to keep things simple here.) We’re also hiding all the dirty work—such as finding the name of the person who was liked—inside the Search Results object, rather than having it muddy up our application code. The best part: we can now write tests to prove that our Search Results object works as we expect:

var ul; var data = [ /* fake data here */ ]; setup(function () { ul = $('<ul><li class="no-results"></li></ul>'); }); test('constructor', function () { var sr = new SearchResults(ul); assert(sr); }); test('display received results', function () { var sr = new SearchResults(ul); sr.setResults(data); assert.equal(ul.find('.no-results').length, 0); assert.equal(ul.find('li.result').length, data.length); assert.equal( ul.find('li.result').first().attr('data-name'), data[0].name ); }); test('announce likes', function() { var sr = new SearchResults(ul); var flag; var spy = function () { flag = [].slice.call(arguments); }; sr.setResults(data); $(document).on('like', spy); ul.find('li').first().find('.like.btn').click(); assert(flag, 'event handler called'); assert.equal(flag[1], data[0].name, 'event handler receives data' ); });

The interaction with the server is another interesting piece to consider. The original code included a direct $.ajax() request, and the callback interacted directly with the DOM:

$.ajax('/data/search.json', { data : { q: query }, dataType : 'json', success : function( data ) { loadTemplate('people-detailed.tmpl').then(function(t) { var tmpl = _.template( t ); resultsList.html( tmpl({ people : data.results }) ); pending = false; }); } });

Again, this is difficult to write a unit test for, because so many different things are happening in just a few lines of code. We can restructure the data portion of our application as an object of its own:

var SearchData = function () { }; SearchData.prototype.fetch = function (query) { var dfd; if (!query) { dfd = $.Deferred(); dfd.resolve([]); return dfd.promise(); } return $.ajax( '/data/search.json', { data : { q: query }, dataType : 'json' }).pipe(function( resp ) { return resp.results; }); };

Now, we can change our code for getting the results onto the page:

var resultsList = new SearchResults('#results');
 var searchData = new SearchData(); // ... searchData.fetch(query).then(resultsList.setResults);

Again, we’ve dramatically simplified our application code, and isolated the complexity within the Search Data object, rather than having it live in our main application code. We’ve also made our search interface testable, though there are a couple caveats to bear in mind when testing code that interacts with the server.

The first is that we don’t want to actually interact with the server—to do so would be to reenter the world of integration tests, and because we’re responsible developers, we already have tests that ensure the server does the right thing, right? Instead, we want to “mock” the interaction with the server, which we can do using the Sinon library. The second caveat is that we should also test non-ideal paths, such as an empty query.

test('constructor', function () { var sd = new SearchData(); assert(sd); }); suite('fetch', function () { var xhr, requests; setup(function () { requests = []; xhr = sinon.useFakeXMLHttpRequest(); xhr.onCreate = function (req) { requests.push(req); }; }); teardown(function () { xhr.restore(); }); test('fetches from correct URL', function () { var sd = new SearchData(); sd.fetch('cat'); assert.equal(requests[0].url, '/data/search.json?q=cat'); }); test('returns a promise', function () { var sd = new SearchData(); var req = sd.fetch('cat'); assert.isFunction(req.then); }); test('no request if no query', function () { var sd = new SearchData(); var req = sd.fetch(); assert.equal(requests.length, 0); }); test('return a promise even if no query', function () { var sd = new SearchData(); var req = sd.fetch(); assert.isFunction( req.then ); }); test('no query promise resolves with empty array', function () { var sd = new SearchData(); var req = sd.fetch(); var spy = sinon.spy(); req.then(spy); assert.deepEqual(spy.args[0][0], []); }); test('returns contents of results property of the response', function () { var sd = new SearchData(); var req = sd.fetch('cat'); var spy = sinon.spy(); requests[0].respond( 200, { 'Content-type': 'text/json' }, JSON.stringify({ results: [ 1, 2, 3 ] }) ); req.then(spy); assert.deepEqual(spy.args[0][0], [ 1, 2, 3 ]); }); });

For the sake of brevity, I’ve left out the refactoring of the Search Form, and also simplified some of the other refactorings and tests, but you can see a finished version of the app here if you’re interested.

When we’re done rewriting our application using testable JavaScript patterns, we end up with something much cleaner than what we started with:

$(function() { var pending = false; var searchForm = new SearchForm('#searchForm'); var searchResults = new SearchResults('#results'); var likes = new Likes('#liked'); var searchData = new SearchData(); $(document).on('search', function (event, query) { if (pending) { return; } pending = true; searchData.fetch(query).then(function (results) { searchResults.setResults(results); pending = false; }); searchResults.pending(); }); $(document).on('like', function (evt, name) { likes.add(name); }); });

Even more important than our much cleaner application code, though, is the fact that we end up with a codebase that is thoroughly tested. That means we can safely refactor it and add to it without the fear of breaking things. We can even write new tests as we find new issues, and then write the code that makes those tests pass.

Testing makes life easier in the long run

It’s easy to look at all of this and say, “Wait, you want me to write more code to do the same job?”

The thing is, there are a few inescapable facts of life about Making Things On The Internet. You will spend time designing an approach to a problem. You will test your solution, whether by clicking around in a browser, writing automated tests, or—shudder—letting your users do your testing for you in production. You will make changes to your code, and other people will use your code. Finally: there will be bugs, no matter how many tests you write.

The thing about testing is that while it might require a bit more time at the outset, it really does save time in the long run. You’ll be patting yourself on the back the first time a test you wrote catches a bug before it finds its way into production. You’ll be grateful, too, when you have a system in place that can prove that your bug fix really does fix a bug that slips through.

Additional resources

This article just scratches the surface of JavaScript testing, but if you’d like to learn more, check out:

• My presentation from the 2012 Full Frontal conference in Brighton, UK.
• Grunt, a tool that helps automate the testing process and lots of other things.
• Test-Driven JavaScript Development by Christian Johansen, the creator of the Sinon library. It is a dense but informative examination of the practice of testing JavaScript.

Si fue en el Mobile World Congress cuando LG presentó al mundo su línea Optimus F, con la que pretendía extender la mano del LTE a aquellos terminales de especificaciones menos punteras, no se desveló al completo. O así lo indican las últimas imágenes filtradas para un nuevo dispositivo que encaja en ella.

Se trata de un Optimus F3 que vendría a ser el más pequeño de la familia, conformada también por el Optimus F5 y F7, que probamos en dicha feria.

Este dispositivo acompañaría con sus 4.0 pulgadas a sus hermanos mayores de 4.3 y 4.7 respectivamente, con algunas especificaciones que se han escurrido a la vez que el render que veis arriba, entre las que se encuentran una pantalla en resolución 800×480 (WVGA), Android 4.1.2 (Jelly Bean), un procesador Dual Core no espeficado y una batería bastante nutrida de 2.460 mAh. Además de, por supuesto, LTE integrado.

De momento, y según apuntan desde PhoneArena viene a competir por la operadora estadounidense Sprint y con unos precios muy agresivos no referenciados, al menos bajo contrato. De cualquier forma, se trata de una línea de terminales que todavía tardaremos en ver por España, debido a la todavía nula adopción de este tipo de conectividad.

En Xataka Android | LG Optimus F5 y F7, los probamos

Tras su vida como una aplicación para el tablet de Apple, NextGuide da el salto a la web y se posiciona como una de las propuestas más interesantes para unir a las diferentes plataformas de contenidos. Pero cuidado, estamos hablando por ahora solamente de una guía avanzada de programación adaptada a los tiempos.

En NextGuide se citan tanto contenido de televisiones que emiten al aire y por cable, como soluciones de streaming y bajo demanda del estilo de Netflix o Hulu, además de iTunes. El propósito de NextGuide es que el usuario pase por su servicio como punto de inicio para una experiencia televisiva más completa.

Nextguide proporciona un potente buscador y mucho toque social gracias a la integración con Facebook. El sistema nos da recomendaciones sobre películas y series, nos permite compartir nuestros gustos y aprende de los de nuestra red social cercana para que siempre tengamos algo que ver.

Para cada programa podemos configurar recordatorios y añadirlo a listas de reproducción. También disponemos de mucha información relacionada, guía de capítulos con la sinopsis, hora y cadena/plataforma de emisión, y hasta trailers en el caso de cine. Por ahora, en EEUU es donde, por invitación, más se puede aprovechar uno de este servicio para teleadictos.

Vía | GigaOm.
Más información | Nextguide.

Usemos productos de Apple, o no, hay que reconocer que los de Cupertino saben cuidar a sus usuarios. Una realidad que se refleja en encuestas e índicas de satisfacción que realizan diferentes agendas. No en vano en Estados Unidos es el smartphone con mejor valoración pero los fabricantes de Android le pisan los talones.

Según el último informe de ACSI (American Consumer Satisfaction Index), la satisfacción entre los usuarios de Samsung y Motorola ha aumentado. Especialmente la del fabricante coreano que ha aumentado un 7%. Según el índice: la mayor registrada en una compañía de telefonía móvil en el lapso de tiempo que usan como medida.

El principal motivo de esta subida, señala ACSI, es el Samsung Galaxy SIII, uno de los terminales que más ha vendido a lo largo del mundo. Esto sitúa a Samsung con una valoración de 76, Motorola le supera por un punto y Apple se queda en una puntuación de 81.

Todavía hay margen de mejora, lo dicen los datos y cualquier usuario que haya utilizando un smartphone de Samsung. Es cierto que en cuestión de dos años han mejorado mucho su buque insignia pero todavía hay pequeños detalles que se pueden mejorar, especialmente en lo que respecta al software.

Ante esta subida en la calidad, y a los constantes movimientos de Samsung para no asociar la familia Galaxy a la marca Android o Google, cabe preguntarse hasta qué punto ambas compañías han aportado a que se haya producido ese aumento en la satisfacción de los usuarios.

Está claro que Samsung ha jugado bien sus cartas, ha mejorado su buque insignia y tiene una de las campañas de marketing más grandes del sector. Sin embargo, Google también ha mejorado bastante la experiencia de Android con Jelly Bean, aunque luego por encima tengamos la capa de software TouchWiz.

Aunque la satisfacción señala al Samsung Galaxy S3 como el principal responsable, se echa en falta que den algún dato más sobre el papel de los terminales de gama media. Sería interesante replicar esta encuesta y metodología en otros territorios donde los smartphones más asequibles tienen más presencia.

Vía | Bloomberg

Los desarrolladores de este navegador han anunciado la disponibilidad de Opera 14 para Android en versión final, una edición que se basa en Chromium 26 y que entre otras cosas llega con un rediseño total de la interfaz de usuario.

Eso permite “ajustarlo mejor a las últimas guías de diseño de Android”, como destacan los responsables de Opera, que también destacan que el navegador es compatible con versiones iguales o superiores a Android 2.3 Gingerbread, una plataforma aún presente en el 38,5% de los móviles basados en este sistema operativo.

Por el momento, eso sí, no hay inclusión de Blink, el fork de WebKit que los desarrolladores del proyecto Chromium anunciaron hace pocas semanas, pero en Opera afirman que ese nuevo motor de renderizado llegará en próximas versiones.

Mientras tanto, han llegado mejoras en muchas áreas, como el soporte WebGL 3D, el soporte de la característica <input type=color>, o una forma más potente y visual de trabajar con la reproducción de audio HTML5.

Rediseño de la interfaz de usuario

La nueva interfaz también es característica destacada, aunque conserva apartados clásicos como Speed Dial o el historial de navegación, que encontraremos haciendo el gesto de arrastrar la pantalla hacia la izquierda.

Si lo hacemos hacia la derecha, encontraremos la nueva página para descubrir (Discover) nuevos contenidos, algo que según indican los responsables de Opera puede ser muy interesante cuando por ejemplo estamos esperando al autobús y queremos darle una oportunidad a esa filtro que Opera propone.

Otra posibilidad curiosa es la de poder mover la barra de navegación a la parte baja de la pantalla en lugar de situarla en la tradicional parte alta, algo que puede favorecer el uso del móvil con una mano en sesiones de navegación.

Compresión y formateo del texto

El modo Off-Road que introducen en esta versión y que está disponible desde el menú permitirá aliviar la descarga de datos, ya que nuestras peticiones pasarán primero por los servidores de Opera Mini, lo que permite que nos beneficiemos de esa característica del otro navegador móvil de Opera sin tener que dar el salto de uno a otro.

En Opera también han destacado que esta versión para Android usa el mismo sistema de justificación y formateo del texto que se usa en Chrome para Android, pero además de ese modo de autoredimensionado (llamado FontBoosting) existe otra opción.

Así, en la configuración del navegador podremos desactivar esa opción y activar el ajuste de texto automático, que obliga a Opera para Android a ajustar las líneas sin importar lo mucho que aumentemos el texto, lo que permitirá evitar la aparición de scroll horizontal en ciertos escenarios con el modo propuesto por Chrome.

Opera14

• Versión de Android: desde 2.3
• Desarrollador: Opera
• Descárgalo en: Google Play
• Precio: gratis
• Categoría: Navegadores

En Genbeta Dev | Blink, el fork de Webkit de Google cierra el debate del estándar de facto que muchos pronosticaban

Hoy, Microsoft, presentará su consola de nueva generación. Salvo sorpresa mayúscula, tendremos una Xbox nueva y con ella se terminará de definir, una vez más, el triunvirato de las consolas domésticas formadas por la propia Microsoft, Nintendo con Wii U y Sony con PlayStation 4.

A falta de unas cuantas horas para que conozcamos cómo será este nuevo sistema, vamos a hacer un repaso de los principales acontecimientos y lo que ha supuesto estos doce años de historia de Xbox, desde que debutara el primer modelo en el año 2001. Nos guste más o menos como consola, ha logrado unos cuantos hechos destacados.

El hardware, evolucionando por dentro y fuera

Cuando Microsoft presentó en el 2001 la primera Xbox, con Bill Gates a la cabeza, muchos recordarán su aspecto: una consola de aspecto algo tosco y muy voluminosa. Llegó un poco tarde a una generación donde PlayStation 2 se lo llevó todo, a día de hoy sigue siendo la consola que más unidades ha vendido en toda la historia.

Su hardware, eso sí, fue bastante potente y aunque en algunos territorios, como Japón, no tuvo la aceptación que en Redmond deseaba. Fue un buen comienzo ya que cuatro años más tarde, y con la lección aprendida, fue una de las primeras en llegar a la próxima generación con un hardware renovado, y también un poco problemático como veremos más tarde.

En la siguiente tabla podéis ver una evolución del hardware:

Xbox Xbox 360 Xbox 360 ‘Slim’ Lanzamiento Noviembre 2001 Noviembre 2005 Junio 2010 CPU Intel x86 Xenon Xenon Procedencia Híbrido entre Celeron y Pentium III IBM PowerPC IBM PowerPC Núcleos 1 3 3 Frecuencia CPU 733 MHz. 3.2 GHz. 3.2 GHz. GPU NVidia NV2A ATi Xenos ATi Xenos Frecuencia GPU 233 MHz. 500 MHz. 500 MHz. Memoria RAM 64 MB 512 MB 512 MB Almacenamiento 8 GB 20-120 GB 4-250 GB Ethernet Sí Sí Sí Wifi No No (con adaptador) Sí Resolución máxima 720p/1080i 1080p 1080p Sistema operativo Basado en Windows 2000 Basado en Windows 2000 Basado en Windows 2000 Dimensiones 320×100×260 mm. 310×80×260 mm. 270×75×264 mm. Peso 3.9 kg. 3.5 kg. 2.9 kg.

En Xbox 360 asistimos a un rediseño de la carcasa, a muchas ediciones especiales y al modelo Slim, que venía a solucionar algunos problemas en el hardware y de paso traer una rebaja de precio para buscar alcanzar la cuota de mercado que no había logrado anteriormente.

El catálogo de juegos, grandes títulos y pequeños desarrolladores

Además del hardware, Xbox siempre tuvo un catálogo bastante abundante de juegos. Al principio, se recurrió a los títulos desarrollados casi de la mano con Microsoft pero con el tiempo, y especialmente en Xbox 360, se empezó a despertar el interés de los estudios externos.

Si hablamos de los títulos creados de forma estrecha con Microsoft, hay tres franquicias que han definido parte estos doce años. Por un lado Halo, para muchos la saga que ha escrito las reglas sobre cómo se tienen que hacer los shooters en primera persona a día de hoy.

Nos dejó un par de entregas en la Xbox original, dos más (de la trama principal) en Xbox 360 y dos spin offs en esta última también. Forza Motorsport también es otra de las sagas que han tenido mucho protagonismo, especialmente en la etapa de la última consola.

Hablando de Xbox 360, la tercera saga que nació, y creció, en esta plataforma fue Gears of War. Ha cosechado mucho éxito, ha sabido renovarse con el paso del tiempo y hoy en día sigue teniendo fans por todo el mundo. ¿Su próximo paso? Todo apunta a que será en otra plataforma.

Aunque los juegos que han tenido un desarrollo estrecho con Microsoft han tenido mucho éxito, y por extensión se han mantenido como exclusividades, también hay que destacar el papel de los pequeños desarrolladores que encontraron el la plataforma de Xbox Live Arcade una forma excelente para llegar a un público más amplio.

Años más tarde, Sony y Nintendo también lo intentaron pero quien de verdad le dio un impulso a la distribución digital fue Microsoft. Allí hemos visto pequeñas grandes joyas como Fez, Toy Soldiers o títulos con un enfoque más casual pero que gozan de mucha popularidad, como por ejemplo la versión digital del juego de cartas Uno o Bejeweled, que sin ser una exclusiva, prácticamente todo el mundo hemos jugado alguna vez.

Poniendo las bases del juego online en las consolas de sobremesa

Decir que Microsoft ha revolucionado el juego online en las consolas domésticas es una afirmación bastante tendenciosa. Sin embargo, es un hecho que fueron pioneros (en un intento sólido) en traer la experiencia multijugador online a las consolas. Nintendo y PlayStation también han contribuido a construir estos cimientos pero quien de verdad apostó al principio por ello fue Microsoft.

Le costó, ya que por ejemplo con la Xbox original lo tuvieron difícil hasta la expansión de las conexiones de banda ancha. Ya con la Xbox 360 la evolución fue más rápida y Live se popularizó entre los más jugones. Por fin las consolas disponían de partidas en red.

En esos doce años han tenido crisis, especialmente con las caídas de larga duración en sus servidores. Sin embargo, con el tiempo y la experiencia de estas circunstancias se han asentado. Además de asentar las bases del multijugador online también innovaron en otros aspectos que luego la competencia copió, como los famosos logros.

Kinect, una apuesta por la innovación

Si hay un momento que me ha impactado y todavía recuerdo como si fuera ayer en la historia reciente del E3 fue el anuncio de Project Natal, posteriormente bautizado como Kinect. Fue un 1 de junio del 2009 y su vídeo de presentación nos mostró que Microsoft pretendía revolucionar el mundo del videojuego con un tipo de interfaz realmente interesante.

Pasó el tiempo y esa demo tan espectacular no cumplió las expectativas de muchos de nosotros. Milo, de Molyneux acabó siendo una cortina de humo, y aunque tenía títulos entretenidos y el sensor funcionaba por norma general bastante bien, no terminó de ser tan bueno como aparentaba.

Eso no quita que Kinect acabara siendo un gran complemento para la consola de Microsoft. Funciona bien, moverse sin usar el mando es útil y algunos títulos pensados para jugar con amigos en las fiestas son realmente divertidos. Su faceta, en mi opinión, más interesante: la destinada a crear contenidos interactivos con el PC que se desligan un poco de los videojuegos en sí.

En esta nueva generación, salvo que Microsoft, confirme lo contrario, Kinect tendrá un papel importante ya que otra de las apuestas por la innovación de Redmond se llama Illumiroom y podría ser uno de los ases de esta nueva Xbox. Dentro de unas horas saldremos de dudas.

Algo más que una consola de videojuegos, lo multimedia

Durante muchos años, vimos la consola como un sistema para una tarea en concreta: los juegos. Es cierto que hubo intentos de introducir algunas funcionalidades más en algunas plataformas pero se trataban de meros complementos que no tenían mucho peso.

Microsoft aquí también decidió apostar fuerte y hacer de avanzadilla para otros sistemas. En Xbox 360, con el paso del tiempo, fue generando un ecosistema donde pretendía incluir a diferentes distribuidores de contenidos. En España no ha tenido tanto peso pero en Estados Unidos ha contado con acuerdos muy importantes con las cadenas americanas.

Todo apunta a que este camino seguirá también en la nueva Xbox que no sólo será una consola sino un centro de entretenimiento donde no sólo querrá competir con el resto de plataformas sino también con las Smart TVs para servir contenidos multimedia.

Este es su legado, donde aunque hubo muchas luces pero también sombras, como por ejemplo el famoso problema de las luces rojas que afectó a un buen número de unidades o las caídas de Xbox Live. Problemas que se han ido solventando con el paso del tiempo.

Dentro de unas horas sabremos cómo será esta nueva Xbox y si en ella se reflejarán aspectos que hemos visto en este artículo. Personalmente, creo que Microsoft va mantener muchas líneas y aunque intentará apostar por ideas nuevas, las bases que ha ido creando estos doce años las tiene muy claras.

Hace poco más de un mes, Xiaomi presentó su nuevo smartphone puntero: el Mi2-S. Su éxito ha ido en la estela de los anteriores modelos y en cuestión de segundos tras su lanzamiento se agotó en China. Aquí las unidades llegan con cuenta gotas y muchas veces tenemos que recurrir a las tiendas online para hacernos con uno.

Mientras en la compañía de Shenzen siguen con este modelo como una referencia, parece que en el horno ya se está cocinando a su sucesor. De momento no se sabe nada de él, de forma concreta, pero unas filtraciones de GizChina, así como unas fotos, parecen apuntar a que tendremos un Xiaomi Mi3 en los próximos meses.

Las fotos que han aparecido, nos dejan ver que este nuevo modelo introduciría un nuevo tamaño de pantalla que, a simple vista, será de unas cinco pulgadas. Por fuera se mantienen el resto de elementos pero parece que la principal diferencia por fuera la encontraremos en el tamaño.

Filtradas estas imágenes, en GizChina comentan que las especificaciones finales de este presunto Xiaomi Mi3 serán excepcionales: procesador Qualcomm Snapdragon 800, 2GB de RAM, 32GB de almacenamiento interno en su configuración más baja y las opciones clásicas de conectividad.

Teniendo en cuenta hacia dónde van muchos fabricantes, si finalmente tiene un tamaño de cinco pulgadas entiendo que este Xiaomi Mi3 tendrá una resolución Full HD. También se habla de que contará con una cámara de 13 megapíxeles por lo que posiblemente se trate del Exmor RS de Sony que ya montan móviles como el Xperia Z y el Samsung Galaxy S4.

De momento sólo se trata de rumores y lo cierto es que este tipo de información resultará una cortapisa para quienes estaban pensando en comprarse el Xiaomi Mi2-S, sabiendo que en un nuevo modelo llegará en unos meses. De ser cierto, posiblemente sea después de verano que será cuando empiecen a aparecer los primeros smartphones con el Snapdragon 800.

Vía | GizChina
En Xataka | Xiaomi presenta el Mi-2S, su nuevo buque insignia, y un smartphone de entrada

Y es que se veía venir, tarde o temprano tenía que llegar el momento en que Google pusiera orden en sus sistemas de pagos, ya que no tenía mucho sentido mantener dos versiones. Y el ganador ha sido Google Wallet, el sistema de pagos que se utiliza en Google Play para comprar aplicaciones, canciones, etc. Hoy se ha anunciado que Google descontinuará Checkout en favor de Google Wallet.

Es algo lógico si tenemos en cuenta que con las novedades presentadas en el evento de Google I/O en la API para desarrolladores será más fácil la creación de ofertas y cupones descuentos, uno de los puntos fuertes de Checkout. Para los usuarios que siguieran utilizando el servicio de Checkout la migración será totalmente transparente, por lo que no tendrán que preocuparse ni realizar ningún cambio, que se realizará en un máximo de seis meses.

Una de las claves de un servicio de este tipo para el pequeño comerciante es poder ofrecer un sistema de descuentos y ofertas que permitan fidelizar al cliente y competir contra grandes superficies y empresas. Esto además de poder tener un sistema que garantice la seguridad de los pagos.

Para muchos usuarios el debate es cuanta información queremos darle a Google y si queremos que tenga nuestros datos de pago, algo que nos puede hacer la vida y las compras mucho más sencillo pero que a la vez da mucha más información de la que muchos desean compartir con la empresa del buscador.

Vía | Xataka
Más información | Google Commerce
En Genbeta | Google Wallet absorbe Google Checkout y se convierte en una plataforma para pagos offline y online

Si no has oído hablar de Leap Motion y sus posibilidades gestuales, la mejor forma de que lo conozcas es junto a un sistema operativo como Windows 8. Los desarrolladores están trabajando en la integración con el sistema operativo de Microsoft, y la verdad es que el vídeo que han preparado no dejará a nadie indiferente.

Los chicos de Leap Motion están transportando cada una de las funcionalidades multitáctiles, de las que presume la última edición de Windows, hacia la interfaz basada en gestos en el aire que es capaz de reconocer el pequeño dispositivo. Manejamos Windows sin tocar el ratón, ni la pantalla.

Prometen que las funcionalidades básicas del sistema operativo, y la navegación web, están disponibles al conectar Leap Motion a tu equipo, sin necesidad de instalar software adicional. Lo mejor es que vayamos con el vídeo, el protagonista de la noticia:

La fecha estimada de salida al mercado de Leap Motion se ha visto retrasada hasta el 22 de julio, esperemos que sea el último retraso. Aunque es más apropiado enseñarlo con Windows 8, el soporte también existe para Windows 7, y pronto nos enseñarán qué tal funciona con Mac OS X.

“Queremos incluir nuestra tecnología en teléfonos, relojes, gafas, y cualquier sitio donde quepa”, Andy Miller , COO Leap Motion

Como podéis apreciar en el vídeo, Leap Motion tiene un tamaño no mucho más grande que un stick USB, y con él se consigue una sensibilidad 200 veces superior al Kinect de Microsoft. Recientemente han anunciado acuerdos con empresas como HP o ASUS.

Más información | Leap Motion

Hace unos meses que está en el mercado uno de los dispositivos más interesantes que HTC ha lanzado en los últimos tiempos, el HTC J Butterfly, un terminal que, por extraño que parezca dadas sus características, no hemos visto oficialmente en nuestros mercados.

En Europa HTC ha decidido ir contracorriente y obviar que todos se han ido a las cinco pulgadas con resolución FullHD, lanzando un HTC One que, si bien se queda en las 4.7 pulgadas, avanza en muchos aspectos al Butterfly.

Es por esto que la firma taiwanesa ya se encuentra trabajando para actualizar su terminal de mayor tamaño con las nuevas especificaciones y componentes que estrenadas en el HTC One, y que podrían convertir al nuevo HTC Butterfly S, que así se llama el nuevo dispositivo, en el más avanzado del panorama Android.

Según se indica, el nuevo Butterfly S contará con una pantalla FullHD, y aunque no se especifica tamaño ni tecnología, parece claro que HTC no abandonará SuperLCD3 ni bajará de las 5 pulgadas.

Además, se integrarán los altavoces estéreo BoomSound y la nueva cámara UltraPixel, además de las mejoras software de Sense 5, con BlinkFeed a la cabeza y Zoe para las funciones avanzadas de la cámara.

Evidentemente, lo más probable es que HTC repita estrategia lanzando en el segundo trimestre este terminal, cuando otras marcas como Sony actualizan sus gama alta y Google presenta sus nuevos Nexus. La mala noticia es que, seguramente, tampoco veríamos en nuestros mercados al Butterfly S.

En Xataka Android | HTC J One incorpora slot microSD para el mercado japonés
Vía | PhoneArena

Sin duda Opera es uno de los navegadores que más me han gustado desde antes de la llegada del smartphone al mundo de los móviles, pero también se ha sabido adaptar a los nuevos tiempos y crear nuevos productos. Hace unos meses llegó la versión beta de Opera Webkit para Android y hoy ya tenemos disponible la versión definitiva de este navegador.

Y no es un asunto menor, puesto que ha supuesto dejar de utilizar su propio motor de renderización para ponerse a trabajar con el que están utilizando hoy en día muchos del resto de navegadores de la competencia. De esta forma Opera pierde una parte de su esencia, de lo que les distinguía del resto.

El nuevo navegador promete ofrecer una mejor experiencia al usuario en la navegación, más sencilla y más rápida. Pero también pensado en hacer un buen diseño del navegador, con una interfaz renovada que añade más claridad a la navegación web.

Entre las nuevas funcionalidades que acompañan a este navegador podemos citar el modo Todo Terreno que está pensado para trabajar cuando estamos en redes que van más lentas, facilitando que la página se ve rápido y bien en cualquier circunstancia. También va a contribuir a que ahorremos datos en nuestras tarifas, algo que seguro muchos apreciamos.

Discover es otra de las funcionalidades destacadas. Con discover podemos acceder a una serie de artículos de actualidad en la web en función de nuestros intereses, por lo que aquí el historial será básico para que nos muestre temas relacionados con lo que ya hemos estado viendo.

Sólo le pongo un pero, para los que usamos también Opera en el escritorio no está disponible Opera Link más que a través de la página del servicio, en lugar de tener sincronizados todos nuestros marcadores, favoritos, etc. A pesar de esto lo cierto es que la nueva versión merece una oportunidad.

Más información | Opera
En Genbeta | Opera cede y se pasa a WebKit tanto en móvil como en escritorio

El próximo 23 de mayo, a las siete de la tarde en el CI La vaguada (Madrid), el reto de la televisión y el cine en la era de Internet salta al escenario de un nuevo Meet The Experts de Xataka.

En la mesa de debate irán apareciendo temas clave para el entretenimiento hoy en día y que forma parte de las inquietudes de nuestra sociedad tecnológica: la llegada del cine al hogar, el papel de los creadores y distribuidores con nuevas formas de consumo, el crowfunding o el boom de los dispositivos móviles prometen una tarde que no debes perderte.

La cita es el próximo jueves 23 de mayo a partir de las siete de la tarde en La Vaguada. Si quieres asistir en directo, no dejes de apuntarte en el formulario. Tenemos plazas limitadas, así que los primeros en resgistrarse serán los que consigan invitación gratuita, que quedará confirmada cuando os contestemos al correo que nos proporcionéis. Y recuerda que también se podrá seguir en streaming en la portada de Xataka.

Cargando…

¿Estáis satisfechos con la oferta de cine y televisión online en España a día de hoy? ¿Cómo será el futuro y los precios? ¿Ven los creadores y productores Internet como una ventaja o una amenaza? Esas son solo algunas de las cuestiones que sobre el escenario debatirán los siguientes participantes:

Mª Carmen Fernández, Actual Directora General de TotalChannel, tiene una extensa experiencia profesional en las áreas de telecomunicaciones, tecnología y electrónica. Es Ingeniera Superior de Telecomunicaciones por la Universitat Politècnica de Catalunya, Master en Comunicaciones Móviles por la Universitat Politècnica de Catalunya y MBA por ESADE Business School. Recientemente fue Directora de Operaciones en ENEO LABS y en InOut TV, gestionando e integrando soluciones avanzadas para el mercado de la electrónica de consumo.

Perfil en Linkedin.

Manuel Cristobal, Productor de Arrugas y miembro de la Academia Española de Cine. Licenciado en Comunicación Audiovisual por la UEM, graduado en dirección en ARTTS International UK y Master en Entretenimiento de TV por el Eric Pommer Institute de Berlín. Desde el año 2001 ha producido ocho largometrajes para el mercado internacional, cinco de ellos en animación, y ha ganado cuatro Goyas a la mejor película de animación.

Perfil en Linkedin | Twitter personal.

Gonzalo Martín es Socio-Director de Territorio Creativo, responsable del área de telecomunicaciones, medios y audiovisual. Es además Vicepresidente para España de Arenas Entertainment. Reconocido analista de los cambios estratégicos que las nuevas tecnologías introducen en el negocio audiovisual, es responsable de Gonzalo Martin.tv, donde habla sobre nueva industria audiovisual.

Nacho Monge (Samsung). TV & AV Marketing Manager en Samsung Electronics, compañía donde lleva más de dos años dentro del departamento de televisiones. Experto en product marketing, promociones y desarrollo de producto dentro del sector tecnológico. Anteriormente trabajó durante más de ocho años en Dixons.

Perfil en Linkedin.

Pablo Romero Sullá es Licenciado por la Facultad de Filosofía y Letras UAM, tiene un máster Mass Communications en la Boston University. Es parte del equipo fundador de Canal+ en 1989, fue Director de Programación de Canal Satélite Digital y después Digital+. Desde 2011 es Director de Contenidos de Yomvi.

Perfil en Linkedin

Roberto Jimenez, espectador desde hace más de 30 años, periodista desde hace más de 15, y coordinador editorial de Weblogs SL desde hace unos cuantos. Editor de Hipersónica, Vida Extra y Xataka, consumo mi tiempo en diversos vicios audiovisuales, algunos de ellos convertidos, afortunadamente, en trabajo.

Perfil en Linkedin.

Hasta ayer, era muy sencillo ser usuario de Flickr. Teníamos dos opciones: usuario normal y usuario Pro. Con el anuncio de la nueva versión del servicio de almacenamiento fotográfico de Yahoo! se han anunciado también cambios en este sentido.

Los usuarios de Flickr nos enfrentamos ahora a una serie de limitaciones comunes. Podemos subir fotografías que ocupen hasta 200MB y vídeos que ocupen hasta 1GB con un máximo de tres minutos de duración a 1080p. No indican nada de un límite de imágenes subidas al mes, ni siquiera para cuentas gratuitas, que ahora también pueden enviar sus fotografías a hasta 60 grupos. Y, por cierto, ya no podemos adquirir las cuentas Pro que conocíamos; tenemos disponibles tres nuevas modalidades.

• Cuenta gratuita. Por el módico precio de cero euros al mes podemos almacenar hasta 1 terabyte de fotografías. Se verán todas las fotografías en nuestro perfil, nada de tener un límite de 200 en nuestra página inicial.
• Cuenta “sin anuncios”. El propio nombre lo indica. El precio que tiene son 49,99 dólares anuales.
• Cuenta Doublr. Como su nombre indica (aunque de una forma extraña), su virtud es duplicar el espacio de almacenamiento del que disponemos en nuestra cuenta Flickr. Su precio no es barato precisamente: 499,99 dólares al año.

Como vemos, desaparece la oferta mágica de las antiguas cuentas Pro: el espacio ilimitado para almacenar imágenes por una cuota razonable. Hoy, con la nueva oferta, sale más rentable ver anuncios (que de momento no son molestos; veremos dentro de unos meses) y no pagar que pagar 50€ al año para no tener ninguna ventaja.

Más información | Ayuda de Flickr
Sitio oficial | Flickr

El año pasado llegaron de puntillas, pero este 2013 las opciones para llevar un cuantificador personal puesto en la muñeca, su sitio ideal en mi opinión, son más.

Una de las novedades de este año en España es la Jawbone Up, que llega en su segunda versión, la de verdad, pues la primera no era más que una prueba que tuvieron que modificar rápidamente.

A continuación el análisis de Xataka de la Jawbone Up.

Jawbone UP, análisis en vídeo

Arrancamos como es habitual con nuestro análisis en vídeo de la Jawbone Up:

La pulsera cuantificadora con mejor diseño

La Jawbone Up es el ejemplo más claro de que, sin un precio desorbitado, se puede dar un excelente diseño y acabado a una pulsera cuantificadora.

La JawBone Up no es un trozo de plástico más, sino que ha sido bien pensada y es la única de las tres grandes (Flex y Fuelband son las otras dos) que puedes lucir con orgullo. O al menos con un poco más que en los otros casos. Además, hay diferentes colores para elegir y es resistente al agua.

Esta pulsera sí que la querrás enseñar

Ese diseño y acabado premium no afecta al peso, grosor ni comodidad. Si aciertas con la talla (hay tres y una guía para ver cuál es la más adecuada para tu muñeca), no notarás que la llevas puesta. Y eso es muy bueno. Además, al no tener cierre fijo sino adaptarse a la muñeca, no se mueve ni baila en la misma.

Los elementos “activos” de la pulsera están en los bordes. En uno de ellos encontramos una capucha con el nombre del producto y que descubre el conector de 3.5 mm que no sirve para escuchar música sino para sincronizar la pulsera con la aplicación, así como para cargar la pulsera mediante un adaptador incluido. La batería, usando la alarma por vibración a diario, nos ha aguantado una media de 8 días, y se carga bastante rápido (unos 90 minutos).

La Jawbone Up no nos da información ni la hora, todo pasa por su aplicación.

El otro extremo es un pequeño interruptor para cambiar entre modo de día y de noche. Luego explicaremos para qué sirve cada uno y cómo se usan.

De lo que ocurre con la pulsera solo te puedes enterar por los dos LEDs junto al botón, que indican cuando está en modo de funcionamiento normal o en nocturno, momento en que empieza a medir la calidad de nuestro sueño.

Simplicidad y comodidad máxima

Así que nada de datos sobre los pasos que llevamos o el tiempo de actividad, ni mucho menos la hora, algo que por ahora, en cuantificadores con formato de pulsera, solo incluye la Fuelband de Nike. La Fitbit Flex, sin posibilidad de mostrar la hora, al menos te indica de forma visual (mediante más o menos luces LEDs iluminadas) cómo llevas de activo el día.

Hay varios colores y tres tallas para elegir Ausencia de conectividad bluetooth, su gran “pero”

A la ausencia de pantalla, hay que sumar como punto negativo la nula conectividad inalámbrica de esta JawBone Up. No lleva bluetooth (el 4.0 sería lo ideal), así que cuando queremos pasar los datos a nuestra cuenta, hay que descapuchar la pulsera y conectarla al puerto jack de 3.5 mm de nuestro smartphone.

No es que sea un gesto que complique mucho la vida, pero no es tan despreocupado como el bluetooth. Además, hay que estar quitándose y poniéndose la pulsera cada vez y aunque parece que aguantará el ajetreo, uno nunca puede descartar que acabe fallando algo. O que perdamos la capucha.

Para sincronizarla hay que conectarla al puerto jack del smartphone

Solo se sincroniza en teléfonos móviles, nada de ordenador. Así que si unimos que no hay panel web y que no se puede sincronizar sin conectarla físicamente a un smartphone, ya tenemos la combinación negativa de esta pulsera. Y es prácticamente la única que le hemos encontrado.

Yo me cuantifico con estilo

La pulsera Up mide básicamente los pasos que damos durante el día. Para conseguirlo emplea la tecnología Motion X, la misma que su rival Fuelband.

En base a esos datos de pasos, la pulsera Up nos determina también información sobre distancia recorrida, calorías quemadas, tiempo total activo, periodos más largos activos/inactivos, así como calorías estimadas quemadas en reposo.

La Jawbone Up “cuantifica” lo que nos movemos, cómo dormimos e incluso qué comemos

Si activamos el modo noche, lo cual se hace maniendo el interruptor pulsado un par de segundos hasta que la pulsera vibre y nos nuestra una luna iluminada, la Jawbone Up comenzará a monitorizar cómo dormimos. Los datos que nos proporciona son el tiempo que hemos dormido, tiempo en la cama, tiempo que tardamos en dormirnos, tiempo que estuvimos despiertos, veces que nos despertamos, así como las fases de sueño ligero y profundo por las que pasamos.

De esos datos la pulsera, o mejor dicho, la aplicación, llega un registro continuo que podemos visualizar en gráficas bastante interesantes. Aquí es cuando más se echa de manos un panel web en condiciones. Con pocos datos la aplicación nos puede servir, pero cuando tengamos mucha información registrada y queramos “disfrutar” analizando nuestra actividad completa (un gustazo con la llamada línea de vida que registra todo lo que hacemos), la pantalla de un móvil se queda muy corta. Además, la aplicación solo es para móviles, nada de tablets.

A mano o mediante en enlace con aplicaciones específicas como RunKeeper o WiThings, podemos introducir actividades concretas que van apareciendo en nuestra línea de vida o historial cuantificado. Para facilitarnos la tarea contamos con un cronómetro.

En la página principal de la aplicación (disponible para iOS y Android) podemos encontrar una gráfica sobre nuestro progreso en ese día, con el tanto por ciento respecto a la meta (la cual podemos configurar tanto en horas de sueño como en pasos al día)

A nivel social la Fuelband y la Fitbit me parecen más completas, y echo de menos, aunque parezca una tontería, recompensas y trofeos por los logros que vamos alcanzando.

Alarmas inteligentes incluso para las siestas

Aunque no nos da la hora, el uso como despertador de la pulsera Jawbone Up es un punto a su favor. Como la Fitbit Flex, lo hace mediante vibración. Es eficaz y ahorra que con quien estemos durmiendo se acabe despertando también.

La alarma por vibración intentará despertarnos en el momento más adecuado según nuestro patrón de sueño

La alarma-despertador (podemos activar hasta cuatro) funciona con un margen de unos 30 minutos respecto a la hora en que queremos levantarnos. En ese periodo, la pulsera, en base a nuestro sueño (profundo o ligero) decide si nos levanta a la hora exacta que le hemos indicado o adelanta dentro de ese margen la vibración. El objetivo es que nos despierte en el momento más adecuado.

Algo similar es la función siesta. En este caso, basándose en nuestro historial de sueño, hay un modo de siesta óptimo (aunque también podemos indicarle nosotros duración) tras el cual nos despierta con la alarma por vibración. Podemos indicarle el tiempo máximo que queremos dormir o estar en fase descanso de sobremesa.

Un registro exhaustivo de lo que comemos

La Jawbone Up no solo quiere cuantificar nuestro sueño y movimientos, sino que también se ofrece a ser nuestra consciencia a la hora de comer.

Mediante un sistema que es el mejor que hemos probado en este tipo de dispositivos, podemos indicar qué comemos y bebemos en cada momento. Esa información aparece en nuestra línea de vida y también nuestro timelime para los contactos, aunque como en todo lo que registra la Up, podemos marcar la privacidad como total.

Me ha gustado especialmente la función para introducir información sobre lo que comemos mediante el escaneo del código de barras del alimento. La información es siempre acertada ya que el lector de la aplicación tiene soporte para códigos EAN, un estándar internacional que genera códigos de barras según tipología y otros datos como pesos del paquete, numero de unidades por paquetes …

Pero lo mejor de la función de registro de lo que comemos de la JawBone Up (aunque en este caso es algo de la aplicación y no de la pulsera, aunque no podemos usar una sin la otra) es que no se limita a darnos información de calorías consumidas sino toda una hoja completa de datos nutricionales, incluido lo que podemos comer, lo que tenemos que ingerir con moderación y por supuesto lo que hay que evitar.

Jawbone Up, la opinión de Xataka

No va a hacer que por arte de magia salgamos a andar, comamos mejor o nos conciencemos de que hay que descansar mejor. Pero las pulseras cuantificadoras son un buen aliado para los obsesos de la información sobre sí mismos.

La JawBone Up es un modelo que tiene en su aplicación su valor más destacado junto con el diseño. Si no te importa la conectividad, que no aporte información visual por sí misma y dependa exclusivamente de una aplicación móvil, sus 130 euros serán una buena inversión para conocerte mejor. Si es que te atreves a hacerlo.

A favor

• Diseño y acabado
• Su completa aplicación
• Registro de comidas

En contra

• Sin conectividad bluetooth
• Ninguna información visual en la pulsera
• Sin panel web

Microsoft presenta hoy su nueva Xbox. Su nueva consola de sobremesa. Y no me estoy repitiendo ni el titular se me ha atragantado.

De las tres grandes, la consola de Microsoft la que mejor ha aguantado en el tiempo, gracias sin duda a Kinect, que la colocó de nuevo en lo más alto de la actualidad y ventas cuando el juego ocasional era lo que había que tener.

Ahora le llega un nuevo momento. No habrá revolución en diseño ni es especificaciones, pero sí en la concepción de consola que Microsoft lleva trabajando años y que ahora reflejará en un nuevo modelo, nacido como algo más. Esto es lo que podemos esperar de la nueva Xbox.

Diseño de la nueva Xbox, ¿a alguien le preocupa realmente

De casi todo se ha hablado en relación con la futura Xbox pero poco se conoce del diseño definitivo. Es una de las bazas con las que están jugando las grandes (mirad si no la borrosa presentación del diseño de la PS4 de Sony). Pero, ¿realmente importa?

A nosotros nos basta con que la consola sea silenciosa, no de problemas de calentamiento y oye, si queda bien junto al televisor, mejor. Pero si no, no pasa nada.

Sin cambios bruscos en el mando, para eso están los tablets y móviles

Tanto Sony como Microsoft no harán cambios radicales en el mando de sus próximas consolas. Ya vimos que Sony introduce una pequeña variación con panel táctil, pero del mando de la nueva Xbox no se espera ni eso.

El diseño de los actuales mandos es perfectamente reconocible, pasa por ser uno de los más cómodos y no pueden permitirse perder a los jugadores “más duros”. Para innovar en formas de control Microsoft juega otras bazas.

La primera se llama Kinect, que evolucionará para ser mejor. No parece que vaya a llegar integrada en la consola. No puede hacerlo al menos la unidad principal, pensada para ser movida y colocada donde sea necesaria, mientras que la propia consola tendrá un lugar más fijo.

Kinect 2 mejorará la definición de captura de los movimientos en todos los sentidos, con mayor velocidad, capaz de distinguir objetos y elementos más pequeños, así como mejoras en el reconocimiento de voz y la gestión de más jugadores. Y ya vendrá con una nueva cámara con calidad 1080p que dejará en ridículo a la actual. Además, es bastante probable que el uso de Kinect sea algo necesario para poder hacer funcionar la nueva Xbox.

Pero más interesante para esta nueva generación de consolas será la multipantalla. Ni Sony ni Microsoft tendrán que buscar la cuadratura del círculo como ha ocurrido con el mando de la Wii U porque el trabajo lo tienen hecho en casa.

En el caso de Microsoft, Windows 8, los tablets y los smartphones con Windows Phone 8 son sus aliados en caso de que quieran introducir la variable táctil o de apoyo en el juego. Y no nos olvidemos de la funcionalidad Smartglass de la que previsiblemente la empresa nos muestre un avance en funcionalidad.

Vuelta a lo conocido

Como ha pasado con la PS3, la nueva Xbox volverá a la arquitectura X86 de la mano de AMD, que pondrá en el corazón de la próxima Xbox un procesador de 8 núcleos a 1.6 Ghz, 8 GB de memoria RAM, disco duro de 500 GB y unidad de lectura Blu-Ray.

La parte gráfica tendrá que reforzarse para recibir una más que probable compatibilidad con contenido 3D.

A nivel de interfaz, no es de esperar que haya grandes cambios si tenemos en cuenta que la idea detrás del actual dashboard de la Xbox 360 es reflejo de la interfaz que Microsoft está promoviendo en todas sus pantallas. Habrá pues más acercamiento a Windows 8, sistema que se postula como el corazón de la nueva Xbox. Esto le servirá principalmente para facilitar la llegada de aplicaciones y potenciar una faceta más allá de la consola de sobremesa para jugar.

Más centro de entretenimiento pero sin olvidarse del juego

Si la consola actual de Microsoft ya os hemos repetido bastante que es un centro multimedia muy aceptable, la nueva Xbox debe dar el paso definitivo para convertirse en multimedia total.

Lo hará por medio de aplicaciones, servicios y la posibilidad de recibir canales de televisión en directo, justo ahora que se ha deshecho de Mediaroom. Luego, con su interfaz y control por voz se realizará la gestión de esos contenidos. Habrá que ver si esta faceta de la próxima consola de Microsoft no divide en dos a sus poseedores dependiendo de si hay acuerdos para contenidos o no.

Y luego tenemos las exclusivas y juegos que ya se estén desarrollando para la nueva Xbox. Como cuentan en Vidaextra, queremos, necesitamos juegos, pues al final, estamos hablando de una consola para jugar ¿no? En unas horas saldremos de dudas. Será a partir de las siete de la tarde.

Sobre la fecha de lanzamiento o disponibilidad, nada se sabe. Es probable que apurando los tiempos, Microsoft la pueda poner en los escaparates para finales de año. No puede esperar mucho más.

Imagen | Concepto de Joseph Dumary.

Tras unir sus caminos, Google ya ha puesto fecha a la muerte de su sistema de pago online Google Checkout. Será en seis meses, y desde ese momento, se centrará exclusivamente en su monedero Google Wallet.

El gigante ya ha avisado a las tiendas que en la actualidad usan el sistema Checkout que la migración será transparente para ellos, y que a partir de ahora dispondrán de un sistema más completo y multipantalla. Si no lo dicen ellos.

Este paso era de esperar tras presentar hace unos días unas mejoras importantes en la API de Google Wallet para facilitar y agilizar el pago electrónico, a la vez que hacer más sencilla la creación de ofertas y cupones de descuento.

Más información | Google.