Incorporando recursos móviles al horizonte de trabajo

Este fin de semana leí un artículo especialmente interesante de Matt Baxter-Reynolds en ZDNet, que quise conservar aquí, para uso posterior, por sus sugerencias en el enfoque a la hora de definir qué devendrá aplicación móvil, y qué no, o no tendrá relevancia.

Do you remember a time before we used to talk about "mobile"?
In reality, it's only been a few years. You don't actually have to go back that far to find a world where mobile was unusual, where the only way normal people got the internet was through a PC that was physically wired into the network. First we got Wi-Fi, then we got cellular data, but mobile was always distinct, always secondary.
Now we're operating in a world where there is no distinction. Plus it's not like mobile has "taken over" and normal desktop computing is in second place. What we're seeing is a world where a connected device is a connected device, regardless of its classification.

Differences

The difference between a non-mobile device and a mobile device is that a mobile device is one where it can be used whilst you're moving, whereas a non-mobile device is one that can be moved from place to place. This is primarily about utility. When you need to interact with a non-mobile device, you have to go through a set-up process, sit down in front of it, and start your activity.
What people want when they engage with mobile is to be able to access their data, and reach out to people in their social networks, without having to go through this specialised set-up process.
If we're particularly looking at enterprise use, a user may choose to use mobile over non-mobile for a number of reasons. For one, it may not be easy to set-up a laptop where they happen to be in space and time -- e.g. a parent dropping their kids off to school replies to an email whilst waiting around. Or, it may just be more of a hassle than what it's worth -- e.g. having a quick look at whereabouts in the city their meeting the next day happens to be during an ad break in a favourite TV show.
In these examples, there is no clear delineation between a "mobile" and "non-mobile" task. What we're looking at is choice in how something is done. The fact that we now use operating systems and form factors that are new is simply an accident. Has Microsoft moved faster into the mobile space, beating Apple and Google, we would have been using Windows as a primary mobile OS too, rather than what we have today where we have this split of operating system use that follows the split of form factor.

Unhelpful

In business what we have today is that people tend to say "We need a Mobile strategy". In that statement, "Mobile" is very much though of as having an upper-case "M".
This is an unhelpful approach. Thinking about "Mobile" (as opposed to "mobile") tends to focus the discussion around technology, whereas it's important when thinking about post-PC to think about the sociological angles first.
There's all sorts of reasons why it's helpful for certain types of professionals to be able to reply to emails whilst dropping their kids off at school. This is after all why BlackBerry became a successful business. The most obvious one is that it allows the user to do something then and there, getting it off their radar, rather than having these trivial "I wonder if…" and "I need to…" tasks gumming up their brains.
BlackBerry is very interesting here because within the enterprise they solved this problem ahead of anyone. BlackBerry invented business-oriented post-PC way before Apple did, simply through this ability to open up access to company systems to certain types of individuals. Specifically, the company system that they opened up was email, seconded by scheduling, and contacts.
What BlackBerry actually did was hit the only really obvious part of "mobile" when it comes to enterprise. If you talk to people who want to take advantage of BYOD, or want their employer to buy them a smartphone and/or tablet, as soon as you have email, scheduling, contacts, and web browsing covered, you have largely done everything that the user wants.
This is part of where thinking about "Mobile" gets stuck. Within the business sphere, there isn't really that much to do other than those basic things. If you focus on "Mobile", all you do is fiddle around the edge of that basic problem.

Alternatives

So if you're a CTO/CIO and you're in the mood for invention and innovation in the mobile space, what do you do?
If you think about "Mobile" as opposed to "mobile", you're going to look at what can be done with the technology. Moreover, you're going to look at what is safe (i.e. what your peers manage to make work), and you're going to respond to what you're being asked (e.g. "I want to reply to emails when I'm dropping the kids off at school.")
If you think about "mobile" as opposed to "Mobile", you're still in danger, as you'll be putting the cart before the horse. "Which opportunities can be delivered best through a smartphone?" is something you may ask.
Asking the question in that way puts up an artificial technical barrier to what you're trying to do. The end user doesn't care if they are mobile or not mobile when they're using what you're provided. What they do care about is that it becomes a tool that fits in with everything else that they have going on.
Perhaps one day that tool is one that they'll want to use in the office at a PC. The next day they might want to use it on a laptop at home. The day after they'll want to access it via their smartphone on a train.
Another danger here is in how businesses buy systems. Going out into the market and asking for "mobile" narrows your options. What users want is systems that are flexible and allow anytime, anyplace, anywhere working. What you need to ask for is systems that offer that flexibility.
The trick with this is to simply ignore "mobile" as a thing -- simply don't think of mobile devices as anything special.
After all, there is no "mobile".

Efectividad en aplicaciones móviles

Releyendo los 12 tips para crear un sitio móvil amigable (12 Tips for Creating a Mobile-Friendly Website) recomendados por Jennifer Lonoff Schiff en CIO...
Algunos de los tips son previsibles y conocidos, alguno difícilmente realizable (Don't go overboard with Java[...script?];  "consider replacing bulky JavaScript libraries like jQuery Mobile with standalone JavaScript"). Pero en conjunto, no deja de ser una buena guía.
Detrás de la simplicidad y síntesis requerida por una aplicación móvil hay un monto de trabajo y conceptualización superior al usual "en otras eras" del desarrollo de aplicaciones, particularmente basados en dos características especialmente dadas en ellas: la vida de una aplicación puede ser considerablemente corta, y debe prevenirse su visualización sobre un número alto de clientes, formados por dos dimensiones concurrentes de actores: sistemas operativos diversos, y visualizadores (browsers) diversos. Y las diferentes versiones de sistema operativo y visualizadores...Sólo puede salvarse de esta matriz de conformidad una empresa que desarrolle aplicaciones para su propio uso...y fuerce el uso de un producto y una versión.
¿Es posible encarar una serie de proyectos móviles sin contar con un marco de recursos que simplifique el trabajo de desarrollo?
Pero un marco tal, en muchos puntos entrará en conflicto con este tipo de recomendaciones, fundamentalmente aquellas que hacen a la construcción en sí misma. En mi caso, trabajando con plantillas de Webclient, existe una oportunidad de refactorización, en la propia capa intermedia. Webclient recurre a Dojo (aplicaciones web) o Sencha (aplicaciones móviles). Si bien técnicamente podría recurrir a javascript personalizado, mucho más económico y adaptado a la recomendación ("Avoid excessive JavaScript in your mobile websites where possible, because it runs differently across different browsers and devices," says Hume. "Even different models of the same phone can often behave quite differently when it comes to JavaScript"), esto requeriría algo así como reinventar la rueda, dedicando un tiempo precioso. Más económico es revisar las propias plantillas cuando resulte necesario, y buscar medios de simplificar su solicitud de servicios del marco Dojo/Sencha. Un compromiso entre resultado final y optimización.

Otro enfoque crítico sobre Windows 8

A las diversas razones que exponen distintos analistas acerca de los problemas críticos que podría experimentar Windows 8, Tim Worstall agrega otro: Windows Metro exige que los viejos usuarios de Windows deban aprender una nueva manera de relacionarse con su sistema operativo. Si se debe aprender algo nuevo, pudiera ser que se optara por algo con un costo menor o directamente gratuito:

Yes, it looks like a good enough tablet operating system. And it’s also quite fine as a desktop operating system. But there’s a problem with the way in which every user now has to learn to use the operating system all over again. And what should worry Redmond a great deal more than some journo like me remarking upon this is the way that at least one fund manager has sold his stock in the company as a result of his confusion over their plans.
(...) The essential point is that at the heart of the Microsoft value equation is their near lock on desktop operating systems.
Even if we all stopped writing new code for Windows (as, to some extent is true, we have done, much writing is now being done in Python and so on which is not platform or OS specific) right now then there are vast numbers of legacy systems out there that will continue to require Windows licenses for decades to come.

But Windows 8 asks everyone to relearn how they interact with a computer. Yes, there’s still that legacy systems tailwind helping the company. But if everyone now has to learn a new OS then why would everyone learn the new Windows? The very change they’re bringing in means that people will be open to changing to a non-Windows platform.

I could argue this from an entirely personal perspective. Sure, I use a computer as the essential tool for making my daily bread and butter. I use Windows simply because that’s what every cheap computer on the market comes pre-loaded with. Plus I’ve near 20 years experience of using one form of Windows or another (no, really, I had Windows 1.0 at one point). But I don’t actually use “Windows” if you see what I mean. I use something that opens a word processor, I use something that will allow a browser to run. And that really is about it. I’m sure my experience of computing is similar to the vast majority of people out there too. We’re no more interested in which OS we use than which spark plugs are in our car’s engine. As long as it works then we’re happy.

Which is the danger of presenting us with an entirely new way (the Metro interface which pretty much insists that you access as if you’re on a tablet) of interacting with the computer. If we’ve got to learn all this new stuff well, why not go off and use some other OS that doesn’t force us to do so? Or one that we don’t have to pay for?

It’s entirely possible even that Metro, the tablet interface, really is a better and more intuitive method of interfacing with a computer. But who cares? Maybe changing where the pedals on a car are is a really good idea too. But can you imagine trying to bring in such a change while still keeping your market share?

 Windows 8 consiste en una paradoja: En su mercado consolidado, el escritorio, Windows 8 no solo no agregará más nada sustancial (Win32), sino que lo considerará "legacy", con todo lo que ello implica. Y sus novedades, su nueva visión (WinRT), las pondrá en un mercado, el móvil, en el que  tiene un peso prácticamente nulo, y donde debe hacerse un lugar entre dos grandes competidores. Una apuesta al filo de la navaja.

Windows Metro y sus clientes corporativos

Acabo de ver una presentación sobre la evolución del mercado de aplicaciones móviles, que muestra una tendencia abrumadoramente inclinada hacia el crecimiento de la venta de recursos móviles (tablets y teléfonos) en perjuicio de un mercado estancado de computadores de escritorio. Ninguna novedad, así como tampoco lo es que el contenido de las aplicaciones varía radicalmente del que poblaba los PCs de escritorio. Se trata de una verdadera explosión del alcance de las aplicaciones, que escalan al uso diario de cientos o miles de millones de personas. El hecho es que la computación corporativa o de negocios pasa a ser una fracción relativamente estable del mercado total, y, comparativamente, con un crecimiento mucho menor que el resto. Esta es, a mi juicio, la razón que explica el estilo del nuevo Windows 8: salir a luchar por una porción dominante en el mercado de móviles. ¿Estará a tiempo todavía, o estará condenado a compartir una porción dividida con la competencia ya suficientemente establecida? ¿Podría haber sido más adecuado, a partir de un núcleo común, desarrollar dos líneas de producto que respetaran las diferencias de estos dos mundos?
El problema está en el universo corporativo: ¿contempla Windows 8 genuinamente este mercado? Por ahora, por lo que veo, no: Fundamentalmente, lo único que se ha destinado a este mundo es Win32, al que se ha declarado obsoleto. Todas las herramientas y lenguajes disponibles apuntan a soportar lo nuevo, básicamente pensado para dispositivos móviles, poco aptos para el trabajo de escritorio. Ni siquiera, al menos por ahora, es posible arrancar una estación Win 8 en modo "tradicional": usted debe iniciar en Metro, y luego cambiar manualmente de modo: se avecina una pesadilla para todos los administradores de servicios de escritorio que tengan scripts de inicio de sistema...Microsoft desprecia las grandes diferencias que existen entre una estación de trabajo y un aparato de comunicación móvil.
¿Será esta la versión final corporativa? Creo que todavía habrá importantes cambios, y, quizá veamos todavía, en "el Service Pack 2", algo más próximo a lo que este mercado requiere. Entretanto, haga sus cálculos financieros para solventar el cambio, o estaciónese en Windows 7.
Mary-Jo Foley comentaba hace poco lo incómodo del nuevo panorama:

While many love the tiled Metro start screen and are looking forward to using it on touch tablets and PCs, many others aren’t keen on it — especially business users who are convinced that Metro will be nothing but a nuisance, especially on non-touch-enabled hardware, and that they’ll do most of their work in the Desktop app on Windows 8.
Paul Thurrott of Windows SuperSite told me a while back that he believed Microsoft would allow users to get around Metro using a group-policy setting, but when I ran that past my contacts at Microsoft, I was told this would likely not be the case. So in the end, it looks like So who knows at this point whether business users who don’t want Metro may get their wish, after all.
(...)
The other big looming question that many business users want more information about is what they will and won’t be able to do when it comes to managing their Windows 8 on ARM (WOA) tablets and PCs.
Microsoft posted a document for download on February 29 (not sure if intentionally or not) that outlined Consumer Preview features for business users. In that document, Microsoft corroborated word that WOA tablets won’t be able to join an Active Directory domain. Some sites have reported that the document also said that Microsoft wouldn’t allow WOA tablets to be managed at all using Microsoft’s own management tools.
(...)
Charles Fitzgerald, a former Microsoft exec now working at VMWare, noted that the domain join limitation means Microsoft won’t be able to one-up the iPad on this front. (And lack of manageability was one of the themes that Microsoft has advised its salesforce to use in selling agains the iPad in businesses.) From Fitzgerald’s March 1 post:

Lack of domain join “means Windows 8 ARM tablets are going to be consumer devices that don’t integrate with the Microsoft enterprise infrastructure any better than the iPad, so Microsoft loses what should have been a major selling point. You will have to sacrifice battery life and go with x86 to get enterprise features and manageability. This is a big blow to Microsoft’s tablet proposition for the enterprise and WOA may be DOA as a result.

Foley todavía dejaba lugar en su comentario a las novedades que la participación de Microsoft en CeBIT pudiera tener para mejorar este panorama. Hasta donde se puede ver, no ha habido cambios notables.

Metro y la herencia de Win32, II

Mientras recopilo información de Windows 8, pensando en el impacto que pudiera tener sobre las aplicaciones existentes (Win32), encuentro estas observaciones de Osvaldo Doederlein, ingeniero en Google:

Microsoft's "squaring of the circle" is by no means perfect: it looks more like an octogon to me. And while I understand and even appreciate the new UI concepts (semantic zoom, layout, typography etc.), its current rendering still looks crude, and (like Peter mentions) the Desktop and Metro look totally alien to each other. Maybe Microsoft can still work on this and make Metro's look more polished, and more similar to the desktop. I like shades, subtle 3D effects, and other decorations that a large display can use (and yeah, OSX uses more elegantly than anyone, though I'm happy enough with Win7). And I'm not visually impaired to need fonts with grotesque sizes everywhere; I'll rather see more data in one screen than need lots of horizontal scrolling (which is really cumbersome on mouse systems). My PC is not a giant Windows Phone!

Now I realize that MS is struggling in the smartphone and tablet markets, and having a single OS and UI that carries over all these platforms will be a big win. Can't really blame Microsoft: Apple is moving in the same direction with Mountain Lion (but not as aggressively as Metro). Even at Google we have Android and ChromeOS, but these platforms are more device-/web-/cloud-centric, and they have no desktop legacy; also, they're not competing on full desktops, to run complex apps like Photoshop (at work, I use Goobuntu for my "macho apps" like Eclipse). The problem is, after years of failure trying to shoehorn the classic Windows into tablets, Microsoft went to the opposite extreme--the total "tabletification" of the PC. Big mistake; there's no reason to believe a device-centric UI will be optimal for a conventional PC, remarkably when running sophisticated applications like IDEs, graghic editors, office suites etc.

Esta es mi especial preocupación. Así como y antes observara respecto a la tecnología de Activex frente al énfasis en .NET, existe un riesgo evidente de que todo el universo de aplicaciones basadas en Win32 y en la interfase visual del Windows [ahora] tradicional, se encuentre ante un futuro de difícil encaminamiento. Por necesidad, volveré sobre esto. Mi cuenta de aplicaciones Win32 a atender es demasiado grande.

Windows 8, WinRT y la herencia de Win32

Este miércoles pasado ha sido un día especial en la pre campaña de lanzamiento de Windows 8: se ha iniciado su "consumer preview", con presentación especial en el Mobile World Congress de Barcelona, y comentarios simultáneos en toda publicación tecnológica que se precie. Sigue resultándome muy curioso que un producto todavía inmaduro, cuyas prestaciones aún no están completas, sea presentado primero a la comunidad de desarrolladores (esto sí es normal) y luego al público en general, tal como está. Sin embargo, puede decirse en este caso en que existe un cambio muy grande en el producto, que puede ser entendible: medir la respuesta, conocer temprano los fallos más gruesos, delinear un mercado de aplicaciones, entusiasmar al cambio. La actividad de difusión entre desarrolladores y socios de negocios ha sido intensa, y sus principales características son bastante conocidas. Desde hace meses se pueden encontrar evaluaciones, comentarios, ensayos, normalmente favorables a Windows 8, y pocas observaciones críticas. ¿No existen reservas críticas sobre los cambios de magnitud que se avecinan?
Sí existen, pero hubiera preferido ver más distanciamiento y criterio en desarrolladores, actores varios de consultoría  y comercializadores, en cuanto al impacto que Windows 8 pueda llegar a tener sobre el mercado actual de usuarios de empresa. Algo que ahora pudiera llamarse un mercado "legacy" o "tradicional", si comparamos lo que hoy usan, y lo que Windows 8 propone.
Partiendo del hecho de que la arquitectura propuesta (WinRT) es diversa y no integrable con la anterior, todo lo que hoy existe está inicialmente confinado al ámbito de Win32, un ámbito sin prioridad de evolución en cuanto a proyectos, y también al momento de ejecutarse. Usted puede construír una nueva aplicación desde cero para ser expuesta en WinRT (y ser aceptada por la AppStore), y se sentirá muy felíz de aprovechar sus ventajas intrísecas y ser de los primeros en el mercado; o tomar su aplicación ahora "legacy" para siempre, analizarla, reescribir todo lo necesario, y portarla a WinRT; o dejarla como está, y confinarla a Win32, es decir, al "escritorio", que ahora es un contenedor subordinado. Lo que está claro es que existe una verdadera ruptura entre las versiones anteriores y la nueva: usted deberá aprender un nuevo API, y deberá replantear cada aplicación, y olvidarse de lo que conocía. Algún comentarista recomienda reconvertir cada actividad diferenciada en un servicio web, para poder ir adelante en la migración. ¿Ha pensado en rever todas y cada una de sus aplicaciones que no sean Office u otros productos nativos de Microsoft?
¿Ha sido la mejor opción definir una arquitectura orientada a recursos móviles como prioridad casi exclusiva? ¿Se ajusta al mercado corporativo? probablemente sí, en el nicho de actividades de movilidad. Pero seguramente no en la mayoría de actividades diarias, atendidas por las llamadas aplicaciones "de escritorio". Este área difícilmente sacaría ventajas del paradigma Metro. Creo que existe una posibilidad de que se repita la situación dada con Windows Vista: una prolongada resistencia a adoptarlo. Tendrá que esforzarse mucho Microsoft para lograr adopcíon en ese área de su mercado.
Presento a continuación algunos análisis, algunos tempranos (último cuarto del año pasado en adelante) y otros muy recientes. Esto es importante porque, como hemos dicho, Windows 8 ES UN PRODUCTO EN CONSTRUCCIÓN, y algunas dudas tempranas se han disipado (y otras han madurado).

Un análisis positivo se puede leer en los comentarios y ejemplos de Harry Pierson (varios). Dos analistas favorables que de todas maneras exponen la magnitud del problema, son Rockford Lhotka y Miguel de Icaza. Lhotka, por octubre de 2011, presentaba una serie de diagramas que mostraban dónde operaban distintas tecnologías, WinRT o Win32. De estos diagramas queda claro que prácticamente todo lo que hoy ejecutamos cae del lado de Win32: Silverlight, WPF, sitios web con plugins (Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common web technologies all run in the desktop web browser. This is the same as web sites work today in Win7), c++, MFC, ATL, Windows Forms. Y se ejecutan en WinRT casi exclusivamente tecnologías nuevas construídas por Microsoft para Windows 8: WinRT .NET y XAML (I expect this to be the most widely used technology stack for building WinRT applications. The .NET available to WinRT applications is (I think) best thought of as being like .NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a bunch of WinRT-specific features and capabilities. The differences between Silverlight and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate. The XAML is very close to Silverlight and WPF, and the types of code you can write using C# and VB are very comparable to what you can write today using Silverlight); HTML5, WinRT c++. Excepcionalmente, también se pueden ejecutar en WinRT paginas web que consistan sólo de HTML, CSS y JavaScript (If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop browsers interchangeably. Microsoft clearly expects this type of web site to become more common over time, though it is interesting that a large number of existing Microsoft web sites are really only useful in the desktop browser)
Resumiendo sus primeras impresiones, Lhotka dice:

Through this series of diagrams, we clearly show how today’s technologies map directly into the Win8 desktop world, still running on the Win32 API. And we show the three technology stacks that enable development of applications on the new WinRT API.
From everything we know today, it seems clear that migrating to WinRT will require effort, regardless of the technology used today, or in the Win8 desktop. Of all existing technologies, Silverlight and then WPF appear to offer the easiest migration. HTML 5, css, and js skills, along with some code assets will also migrate, but there’s a non-trivial architectural difference between web development and smart client development that shouldn’t be overlooked.

por su parte, Miguel de Icaza estudia detalladamente el nuevo modelo enfocado en .NET, y en su detalle podemos dimensionar la dificultad de readecuación a Windows 8 y su API. El API sigue un modelo asincrónico (Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild. With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous); .NET pasa a estar disponible parcialmente en el nuevo modelo (Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT. When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8. And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed)

Invito a seguir sus observaciones, para ir teniendo una idea de cuánto trabajo deberá afrontar en estas condiciones para adecuarse.

Para no abundar, recomiendo la lectura del resumen de dificultades comentada en Techrepublic por Justin James. De las más importantes mencionadas, el modelo asincrónico, la falta de acceso directo a disco, el uso de pantallas táctiles, el énfasis en la nube. Hay más, pero quizá sea preferible que lo lea directamente.

Esto es sólo un pequeño resumen, para que usted piense y estime los tiempos por venir, y vaya calculando decisiones. Una vez más, sería valorable que desarrolladores, implementadores, consultantes, comercializadores, e influyentes en general, se ocuparan del impacto de la adopción del producto, y no sólo del brillo de las novedades. Tras muchos años de hegemonía, también Microsoft tiene un patrimonio "legacy", y alguien debería recordar que eso significa muchas horas de trabajo, y mucho dinero invertido.

Java y su futuro

Advertencia escrita al pie de la mayoría de las páginas que refieren a Java, según los "viejos" enlaces de Sun:

"Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract."

En los últimos dos meses o algo más, he necesitado recurrir diariamente a consultas del API de Java, a su documentación, y a la descarga de algunos de sus productos. Y encuentro cambios no muy tranquilizadores en la estructuración de la información que tradicionalmente ofreció Sun para su Developers Network: por un lado, el estilo de los avisos de Oracle reservándose sus derechos; por otro, cambios en la organización de los materiales. El primer cambio sugiere que Oracle podría ser más restrictivo en la apertura de Java, al menos en cuanto a los servicios de promoción que solía tener Sun (educación, lecturas, disponibilidad de materiales). El segundo quizá sea más bien una cuestión de criterio en la construcción de un sitio para que sea usable, que parece que se está transformando en algo así como ¿para qué lo voy a hacer fácil si lo puedo hacer difícil?
¿Ha tratado de descargar un SDK de Java? La navegación puede derivar desde un inicio razonablemente claro hacia un cambio confuso de contenido de paquetes de descarga y versiones, bastante distinto del simple y claro que antes existía. Haga la prueba. No resultará sencillo volver a la misma página de la que ha partido: da la impresión que el sistema asume conocimiento de la navegación anterior, y las nuevas páginas varían el objetivo en función de esto. Los resultados obtenidos pueden ser desconcertantes. Oracle está desarrollando lo que es por ahora una capa intermedia que acompaña sus políticas para llegar luego a las páginas (al menos para el API) que previamente existían, estas sí, con la simpleza que Sun le había dado a la documentación. Sin embargo, temo que esto no va a quedar así, y progresivamente este nuevo estilo de navegación se extenderá a toda la documentación y descargas. Ya en algún nicho lo he encontrado así. Puede ser exasperante buscar material específico.
Esperemos que sea un problema de familiarización...