Microsoft Inventó el IPad

Por cosas de la vida o no, aveces algunos tienen geniales ideas que otros terminan explotando y llevándose el mérito de ellas. Una de estas ideas es el IPad, que créanlo o no, se me hace que Microsoft lo inventó. Hace un par de semanas estaba leyendo el SDK de Windows Vista, el que viene incluido con mi IDE Delphi 2009. Este SDK fue lanzado al rededor de finales de 2006 o a más tardar enero de 2007 (tres años antes de que apareciera el primer IPad). Casi se me ponen los pelos de punta cuando vi la siguiente imagen en un artículo del SDK, artículo que por cierto habla sobre las interacciones que tienen las personas hoy en día con las computadoras:

Tres ilustraciones que muestran el principal uso que se le da a los IPads

En esta imagen hay tres ilustraciones en las que perfectamente uno podría pensar que se tratan de un IPad -un poquito más grande claro-.

No encuentro la fuente para citarla aquí, pero recuerdo muy bien que en una de las últimas conferencias dadas por Bill Gates antes de salir de Microsoft, él hablaba de interacciones con aparatos muy similares al IPad. Según él esto aparatos serían el futuro de la computación móvil y no las Netbooks -las que son un fastidio por cierto-. Seguramente los ingenieros de Microsoft no supieron captar la idea y dejaron perder un gran negocio. Al final aparecieron con un proyecto fracasado que se llegó a conocer como Courier.

De esta historia creo que podemos sacar una moraleja: Cuando veas que alguien tiene una idea y no le funciona, puede que aún así sea una gran idea nada más que mal captada y ejecutada, por lo que aún puedes mejorarla y beneficiarte de ella.

P.D.: Las imágenes ilustran a los fallidos Slate PC.

Anuncios
Etiquetado , ,

Usando las funciones de la Barra de Tareas de Windows 7

Acabo de leer en el blog de la JEDI Windows API que un grupo de desarrollares están creando un set de componentes para implementar desde Delphi las nuevas funcionalidades brindadas por la nueva barra de tareas en Windows 7. Un inconveniente es que estos componentes están basados en la implementación JEDI de la api de Windows. Por esto puede ser que sea un poco complicado utilizarlos para desarrollares noveles. Aúnque la recomiendo porque es muchísimo más completa que la que trae Delphi.

Estaré atento a este proyecto y cuando llegue a entenderlo e implementarlo es casi seguro que les comentaré y brindaré un pequeño tutorial. Por el momento solo he leído la documentación MSDN al respecto, y creanme, no está muy complicado trabajar con la genial barra de herramientas de Windows 7.

Pueden revisar el código de los mencionados componentes desde este enlace.

Etiquetado

Messagebox con etiquetas personalizadas

El problema:

Con la llegada de Windows Vista, los clásicos mensajes de dialogo en Windows serían -según muchos- cosa del pasado. Estoy hablando de la llegada de los nuevos TaskDialogs. Siendo muy potentes tienen unos inconvenientes que nos impide acogerlos al cien por ciento. Primero: como desarrollares responsables, no podemos -por el momento- desarrollar exclusivamente para Windows Vista y versiones posteriores. Además, desde Delphi y su implementación de los TaskDialogs mediante la clase TTaskDialog no puedes mostrar este tipo de mensajes cuando los temas del sistema están deshabilitados. Por último, al ser muy potentes tienen cierta complejidad que para tareas sencillas sería más cómodo hacer una simple llamada a la función Messagebox.

Sin embargo, los viejos MessageBox de Windows tienen un problema de usabilidad: El usuario tiene que leer todo el mesaje para poder tomar una decisión. La solución a este problema está en usar etiquetas descriptivas en los botones y dejar a un lado los viejos “SÍ/NO/CANCELAR/etc.”. Obviamente surge la pregunta: ” ¿Cómo puedo cambiar las etiquetas de este tipo de dialogo desde Delphi? Es muy sencillo y pasa por utilizar Hooks proporcionados por la misma API de Windows.

Sigue leyendo

Etiquetado , , ,

Delphi XE [ni siquiera vale la pena escribir al respecto]

La semana pasada se anunció las nuevas características que ofrecerá la nueva versión de Delphi. Cuando tienes un blog te atrae la atención escribir y opinar nuevas noticias, pero aveces hay algunas que no valen la pena gastar tu tiempo en ellas. Una de estas es la nueva versión de Delphi. Me entristece pensar esto pero es lo pienso.

La única nueva característica relevante de Delphi es la integración con Subversion. Lamentablemente en el video de presentación se echa de ver que ni siquiera es completa pues parece que necesita de TortuiseSVN para funcionar. Sino es así y me estoy equivocando, entonces de igual manera no es completa, pues no veo todas las funcionalidades que TortuiseSVN te ofrece. Habría que ser bien tonto para pagar un montón de dólares solo para tener esta característica, la que sin necesidad de actualizar podrías complementar gratuitamente con TortuiseSVN -herramienta que yo utilizo en mis desarrollos-.

Hay algunas entradas referentes a la nueva versión de las herramientas de Embarcadero, sin embargo estas son fácilmente refutables:

Desarrollando Aplicaciones IPhone con Delphi Prism XEPor Adreano Lanusse. Mi opinión: Adriano, Hombre precavido vale por dos. Si Apple ha dicho que las aplicaciones desarrolladas con herramientas no aprobadas están prohibidas, por qué arriesgarse a perder una inversión desarrollando con Delphi Prism? Puede que Apple te la acepte en un principio, o pueda que no. Si te la aceptará, nada te salva que te la quiten en un futuro. Entonces, por qué arriesgarse?

[ACTUALIZACIÓN 9/9/10] Apple cambió su política de aceptación de aplicaciones. Ahora empezará a aceptar aplicaciones que puedan estar inscritas en varias herramientas. Según ellos la decisión fue por la opinión de la comunidad. Obviamente, conociendo a Apple, esto es mentira. Lo que los impulsó a echarse para atrás fue sin duda Android.

Lo que opinan los Beta Tester de RAD StudioPor Tim. Cuando leí estos “extractos de opinión” mi sentido común se hizo oír más que las palabras allí escritas. Embarcadero, no sos el primero en contratar a un blogger para escribir cosa bonitas sobre tus productos!

A medida que valla encontrando más tontas entradas las iré colocando acá.

Por el momento mejor dejo de perder mi tiempo escribiendo sobre XE. Talvez la crítica no hubiera sido tan dura si embarcadero hubiera evitado generar expectativa con todos esos subproyectos que tenía para delphi (la multiplataforma, los 64bit, etc). Pero bueno, todo al final ha sido una decepción que podría expotenciar la perdida de desarrollares Delphi.

Me abstengo a opinar sobre las estrategias de negocio que embarcadero tiene para Delphi -si es que las tiene- porque eso sería especular demasiado.

Etiquetado ,

Hoy es OpenSolaris, mañana OpenOffice

Tan sólo hace un par de días Oracle anunció que dejaría morir a OpenSolaris. Noticia que sinceramente no me sorprende y de la que a la larga me alegro. Porque espero que los recursos técnicos brindados por la comunidad OpenSource a este desarrollo se reorienten a Linux u otros proyectos más favorecidos.

Pero que tiene que ver OpenOffice con lo que le ha pasado a OpenSolaris? He leído una entrevista a Edward Screven, Chief Corporate Arquitect sobre la importacia del código y estándares abiertos en donde se ha mencionado brevemente a OpenOffice. Según Screven, OpenOffice está relegado a un pequeño departamento que se dedica al desarrollo y promoción de OpenOffice y que la empresa como tal está más interesada -según parece- en un servicio1 llamado Oracle Cloud Office, que a cómo su nombre indica, no es más que una aplicación ofimática basada en la Web, que obviamente entrará a competir directamente con Google y Microsoft.

Por todo lo anteriormente dicho, sin querer creerme un Nostradamus, predigo que en un futuro no muy lejano, Oracle hará un anuncio muy similar al que acaba de ocurrir con OpenSolaris, nada más que con respecto a OpenOffice. ¿Por qué? Básicamente porque ellos están viendo que el futuro está en las plataformas Cloud y que Microsoft Office está tan penetrado en la industria que tomaría mucho esfuerzo y tiempo quitarle el trono. Esfuerzo y tiempo que no vale la pena invertir ya que las reglas del juego están cambiando para bien y mal de unos y otros.

Me da una inmensa lástima pensar esto, pero creo que es obvio que sucederá. No descarto la posibilidad de que cuándo esto suceda otros tomen el desarrollo de OpenOffice. Pero al momento que suceda esto, las razones por las cuáles Oracle mató a OpenOffice serán más validas que hoy en día. Inevitablemente, esta gran aplicación pasará al cementerio informático con un lema: “La aplicación que debió ser lo que nunca logró ser…”

—–
1 En la entrevista Oracle Cloud Office es mencionada como una “Tecnología” pero bien sabemos que las empresas son buenas a vender cualquier cosa con el lema: “Tecnología nunca antes vista”

Etiquetado ,

Nick Hodges deja Embarcadero

Acabo de leer una noticia importante para el mundo Delphi: Nick Hodges deja Embarcadero. Nick ha sido durante un par de años el director de desarrollo de Delphi. La mayoría de los comentarios en la red acerca del asunto empresan su lamentar por tan mala noticia. Otros son de la opinión que todo cambia y la esperanza habrá que mantenerla en que llegue un director aún mejor para Delphi, opinión que comparto sinceramente.

Sólo espero que la perdida de Nick no valla afectar tanto a Delphi como lo hizo la partida de Anders Hejlsberg :(

Enlace a la noticia: https://forums.embarcadero.com/thread.jspa?threadID=40037

Etiquetado ,

Hola Mundo!

¡Hola! Mi nombre es Christopher Ramírez. Soy un joven nicaragüense que su trabajo de tiempo completo consiste en desarrollar aplicaciones Delphi cotidianamente además de algunas otras cosas. Me encanta saber de todo un poco, de vez en cuando navego por Wikipedia leyendo sobre temas que me interesan. Soy  miembro desde hace ya un par de años del ClubDelphi.com, para mí el mejor foro de habla hispana relacionado a Delphi.

El último tema sobre el que he estado apasionado desde hace ya varios meses es el diseño de interfaces graficas de usuario. Por lo que esperen en mis Posts cierta inclinación al diseño de interfaces. Espero principalmente escribir a menudo  -entre otras cosas- temas relacionados al desarrollo de aplicaciones, especialmente desde la perspectiva de la usabilidad y el diseño estético.

Cuando se me ocurrió la idea de iniciar un nuevo blog acerca de Delphi, una de las cosas que se me vino a la mente fue: ¿Para qué escribir sobre un tema que entre la mayoría de desarrollares ya no tiene tanto interés como lo tendría WPF, Visual Basic, ASP o PHP? La respuesta sencillamente es: Porque es el tema que mejor manejo y porque amo a Delphi :)

Les mando a todos un saludo desde acá, mi cede ;)

Usa Verbos en las Etiquetas [Léelo!]

Para iniciar  mi primer post, quisiera hablar de un tema muy importante pero aveces descuidado entre algunos desarrolladores. Se trata de las etiquetas que le asignamos a los botones. En mi presentación personal he dejado en claro que mis artículos tendrán connotación hacía la usabilidad, por eso es que quiero empezar con con este tema.

Uno de las principales reglas para hacer un buen diseño, es evitar que el usuario piense en cosas irrelevantes. Esto quiere decir, que la funcionalidad presentada por la interfaz debe ser obvia, no ambigua. Siempre es mejor utilizar un verbo o una simple palabra que describa lo que un botón hará, antes de utilizar el típico “Aceptar“. Fíjate en el siguiente ejemplo:

Venta de datos de contacto con el clásico "Aceptar"/"Cancelar"

La ventana anterior incluye el típico “Aceptar”/”Cancelar”. Sin embargo, la funcionalidad el botón Aceptar puede ser ambigua en este caso. ¿Qué es lo que  “Aceptar” realmente hace?

En cambio…

Venta de contacto mejorada visualmente

La ventana anterior deja muy en claro lo que el botón, anteriormente llamado “Aceptar”, realmente hace -Guarda los cambios que pueda realizar un usuario-.

Aunque no parezca, estos pequeños cambios hacen un gran cambio en la usabilidad de nuestras aplicaciones. Y lo más importe,  aumentan la confianza que desarrollan los usuarios con nuestras aplicaciones, al evitarles sentirse que pueden cometer un error porque no saben lo que realmente están haciendo, ya que la interfaz es ambigua. Porque un Look & Feel” no es solo una cuestión visual, sino sentimental -de ahí el “Feel” en la expresión-.

En un futuro Post estaré ampliando este mismo tema. Abarcaré como resolver con Delphi este tipo de problemas en los MessageBox de Windows. Por ahora me despido. Saludos desde mi cede ;)

P.D.: Si hay llegado a este Post por la palabra “Léelo!” en el título, deberías darte cuenta de lo eficaz que es una simple palabra.
Las ventanas aquí mostradas fueron realizadas en Delphi 2009
Etiquetado , , ,