Archivo

Archive for the ‘Uncategorized’ Category

Dear UX/Designers. STOP THIS NONSENSE!!

Jueves, 19/Abr/2012 Deja un comentario

Please UX/Designers of the world:

STOP MAKING BUTTONS APPEAR OUT OF NOWHERE WHEN HOVERING EMPTY AREAS OF WEB PAGES/PROGRAMS. PLEASE.

Empty areas are used to click on them to gain the focus of an application. Imagine the horrid side effects of clicking on random buttons scattered like mines all over the place, which fade in when you hover them. Have you imagined it? Ok. I’ve also experienced it and believe me, it’s not funny.
Last time you do it, please.

Thanks and have a good day.
____________________________

Por favor, UX/Diseñadores del mundo:

PARAD DE HACER APARECER BOTONES DE LA NADA CUANDO SE PASA EL RATÓN POR PARTES VACÍAS DE PÁGINAS WEB/PROGRAMAS. POR FA VOR.

Las áreas vacías se usan para hacer click en ellas y así obtener el foco de la aplicación. Imaginad los horripilantes efectos secundarios que podría conllevar hacer click en todo tipo botones, escondidos aleatoriamente como minas por todos lados, en cuanto pasas el ratón por encima ellos. Lo habéis imaginado? Sí? OK, yo lo he vivido, y en serio, no es nada gracioso.
Que sea la última vez que lo hacéis, por favor.

Gracias y que paséis un buen día.

_________________________________________________________________________________________

Post to Del.icio.usShare it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

“Dead” pixels in my IXUS digital camera (And a fix using CHDK !!)

Lunes, 27/Feb/2012 Deja un comentario

Some days ago, I made a nice trip to Thailand, and, as always, I take my IXUS 80 IS with me, to enjoy the typical photo sessions I usually do: some long exposure ones, some random shoots, etc… CHDK is installed in my SD card, so all the bunch of extra features it offers, was there for me to enjoy also.

Anyway, when coming back home, I started downloading and processing all the pics I took. Then suddently something caught my eye: Some dark (and mainly slow) photographs showed pure red and or blue pixels where they should show black colours. I checked it against 4-5 pics and then I could confirm it: These misbehaving pixels were exactly the same ones across those pics, as they appeared in the very same location on every photograph.
One extra thing that confused me a bit more, was that on some long exposure pics I also took, those rogue pixels WERE NOT THERE!!

I thought, “oh no, my wonderful IXUS’ CCD is broken, and in a very funny way!!”. As always, when something like this happens, I just google some info to see if I could do something about it. In yesterday’s googling I’ve learned some things:

1.- These pixels that show up randomly coloured, are not really broken. They’re “over sensitive” (Oh boy!)
2.- This oversensitive behaviour shows up in dark areas, and mainly doing “slow shots”, (1/3 s. etc…)
3.- All cameras aparently have this kind of pixels (there’s no warranty of a 100% funny pixel free camera).
4.- There’s a nice fix for it!! CHDK itself…

As I said before, when doing long exposure shots, these funny pixels didn’t show up. Then I started thinking, “what’s the difference between a “slow dark shoot” (night shoot against people in a club, for example) and a ULTRA SLOW shoot (+3 minutes) using a tripod against the night sky ? ”

Then some pieces of the puzzle gently fitted on my mind:
-When doing long exposure shots, I could remember the tedious “Wait, processing…” banner appearing after each exposure. That means 1 min exposure means 1 min black frame noise reduction calculation time. 5 mins exposure, 5 mins noise reduction against a black frame. And so on.
Apparently, “those funny pixels” are included in the noise reduction calculation, and thus, when substracting them from the real shot, they just disappear from the final .jpg file, as expected, and as I confirmed. Yay!!

So, when I take “normal slow shoots” at night (not long exposured ones), the “noise reduction process” is not peformed at the end of every shoot. Shouldn’t it be nice if I could force it somehow? And then, reading some CHDK forums here and there, someone hit the nail claiming a strange solution buried in the “RAW Options” submenu. Read on:

Apparently, if you enter onto that submenu (RAW Options), there’s one option there named “Black frame noise reduction” (Or similar name, mine is in Spanish) which is set to AUTO by default. Apparently, AUTO means “Noise reduction post processing will be used in long exposure shoots only”, and nowhere else.
Someone could say, OK, but why is this option “hidden” in the “RAW Options” submenu? I have no idea at all, because setting it to ON forces “Black frame noise reduction” post processing on EVERY shot, not only RAW ones, and not only “long exposure ones”.
That means, even I’m NOT enabling RAW file creation when taking pics (just HQ jpg files are OK for me right now), and even though CHDK reads and uses “RAW Option” submenu settings (even I told it not to store RAW pics on my SD card), I get bad pixel free pics (!!), even when saving them as JPG files!! And all because of the “ON” setting instead of “AUTO”.

Is there some known caveat? Well, “yes”: Now every pic gets “Black Frame Noise Calculation” times after every shoot. But there’s something nice about it: 1/3 s. pic gets 1/3 s. processing time, which is completely affordable in terms of patience waiting for the camera to be ready for the next shoot.

Now EVERY (dark) photo is JUST BLISS, with no random coloured piexels around, (and I would even say generic noise amount is lowered just a bit, I hope it’s not some form of CHDK Placebo 🙂 …

As always, CHDK: Giving proper solutions to everyday (1st world) problems!!

_________________________________________________________________________________________

Share it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized

¿Qué pagaríamos si pagáramos 5 € al mes por Spotify?

Sábado, 16/Abr/2011 19 comentarios

Spotify, desde el 1 de mayo de 2011, se habrá convertido en un programa completamente inútil para quien no actualice su cuenta gratuita a alguna de las dos modalidades de pago (Premium o Ultimate) existentes. (Todo ello explicado en el infame anuncio de mediados de abril de 2011, aquí).

Lógicamente, dos grupos claros (y previsibles) de gente han aparecido llenando los blogs de los países donde Spotify opera(ba):

1.- Los que dicen: “Adios Spotify, hasta aquí hemos llegado”.
2.- Los que dicen: “Pagar 5/10 € al mes es baratísimo, no me creo que haya gente tan llorona por el mundo”.

Yo soy un ferviente defensor de la primera opción. Y no por el típico lloriqueo de “todo lo queremos gratis”, (que es una de las banderas que mucho descerebrado está aprovechando para enarbolar). Nadie está hablando de “los músicos no merecen ser pagados”. Al contrarísimo

En cualquier caso, la versión gratuita de Spotify, “no es tan gratis como ellos quisieran”, aunque lo parezca, ya que se nos obliga a escuchar anuncios que más o menos a regañadientes uno ya se ha acostumbrado a ignorar (o no, Melendi sé donde vives! 😀 ).
Es más, son anuncios que están más o menos geolocalizados, es decir, son anuncios con punto de mira, dirigidos a targets objetivos y acotados, etc… Anuncios “de calidad” por así decirlo.

Algún listillo dirá: “Pero bueno, el ancho de banda que le supone al señor Spotify ir sirviendo canciones por un tubo día tras día, ¿eso quién lo paga? El señor Spotify debe estar ahogado bajo una montaña de facturas de su proveedor de internet, ¿no?”. Pues no, porque el protocolo de comunicaciones del programa Spotify (que es una auténtica maravilla, todo hay que decirlo, that is, el protocolo. Y también el programa, va), está basado en tecnologías P2P. Sí, como el sempiterno, confiable y robustísimo emule, como el demasiado mainstream bittorrent, como ver los partidos de la liga por ‘los chinos’, etc…

Los datos que componen las canciones que yo escucho y que son bajados desde otros usuarios de Spotify que escucharon esas canciones antes que yo, en cuanto los oigo, el programa los reprocesa y los reentrega a la nube Spotify otra vez, para que más usuarios quieran escuchar esas canciones después de mí, lo puedan hacer.
Es decir, el protocolo Spotify está usando el ancho de banda de los usuarios, por tanto somos nosotros, los usuarios, quienes estamos pagando este ancho de banda al señor Spotify de manera altruista sin recibir nada a cambio. Bueno, sí, recibimos canciones, pero éste era el trato no?

Resumen: Yo ya pago a mi proveedor de internet (Teléfonicas/Jazzteles/Oranges/Ono’s/Yacoms/nosentendemos… no?), señor Spotify, no sea tan gorrón, va.

Se puede deducir entonces que el ancho de banda (lo que la gente populachera llama “los megas”) que usa el programa Spotify se compone en un 95% (por decir algo, es para entenderse) por tráfico que generan los usuarios al escuchar las canciones y al usar el programa. Efectivamente, sí, el señor Spotify, sirve la primera versión de la canción a la red desde sus propios servidores que él paga, pero una vez ha sido entregada esa primera versión, la que él alojaba, raramente ésta volverá a ser usada para servirla a otro usuario de nuevo. Este usuario la obtendrá de algún otro que la haya escuchado antes.

De esta manera el gasto en entregar canciones a la red desde los servidores del señor Spotify es marginal. No sería marginal si el señor Spotify tuviera que entregar todas la canciones directamente a cada usuario una por una, (que el señor Spotify no es tonto), pero eso no es lo que está pasando.

Otra cosa genial que pasa con el programa Spotify, es que en el disco duro local de cada usuario que lo usa, quedan almacenadas copias (cifradas y “poco usables”, tranquilos) de las canciones que se van escuchando. Esto tiene el interesante efecto de que, si nos ponemos a escuchar una canción por 10 veces seguidas (por ejemplo con la típica opción Repeat1 o similares), la primera vez, la canción bajará de “la nube Spotify” (recordemos, conformada al 99% por otros usuarios, casi nunca por los servidores centrales de Spotify). Pero qué pasará la 2ª, 3ª, y siguientes veces que oigamos esa canción? Pues que se reproducirá la copia local cifrada que habrá quedado en la caché local del programa, alojada en nuestro disco duro, con lo que el gasto de red para el señor Spotify (y de paso también para nosotros), tiende a 0.

En este punto, los partidarios del “pagar 5/10 € no es tanto”, todavía podrían decir: “Pues mira chaval, motivo de más, mis euros se van directamente a los autores(je)/discográficas/SGAE’s de turno, en vez de al señor Telefónica, ¿no es lo deseable?”. Y yo diría, “bueno sí, si yo fuera un megamelómano que escucha milones de canciones, discos, autores, etc… no te digo yo que no”. Pero resulta que no es así; en mi caso, y en el de la mayoría de gente que conozco. Simplemente “queremos escuchar un grupillo de canciones de vez en cuando para matar el rato mientras trabajamos”.

De todo esto yo deduzco lo siguiente además: Resulta que si cada uno estudia los hábitos particulares de uso de cada uno en Spotify, cuando se van añadiendo canciones y se crean listas y demás, siempre hay una cierta “efervescencia” en los primeros meses de uso del programa. Esta efervescencia se traduce en “añadir canciones a saco”, “crear listas como locos”, “crear carpetas”, y en general, “aterrizar en el programa”.
Pero en cuanto pasan 5-6 meses (o el tiempo que sea), las canciones que uno acaba escuchando acaban siendo un conjunto más o menos cerrado que no crece. Vale, sí, uno siempre puede añadir alguna canción nueva muy de vez en cuando a las listas, pero ya no es la locura de los primeros momentos. Yo al menos no tengo el tiempo para currármelo tanto.

Con esta explicación dónde quiero ir a parar? Pues a que “una vez yo pago mis 5/10€ al mes“, si no voy añadiendo muchas canciones nuevas a mi repertorio de listas y carpetas (en mi caso, insisto, noto que es lo que me pasa), estaría pagando por escuchar canciones que ya están localmente alojadas en mi disco duro, ya que al ser mis canciones favoritas, por el hecho de escucharlas con frecuencia, se quedan en la caché local en vez de bajar de internet.
Y aquí es donde me chirría todo, es decir, mis 5/10 € exactamente ¿”qué están pagando”? “Mi canción favorita ya se bajó hace meses, el autor ya cobró de mis 5 € (je), y aún así sigo escuchando esa canción porque me gusta mucho, el resto de sus canciones son un truño, pero esa en particular me gusta mucho… Sólo por eso, ¿tengo que seguir pagando al autor 5/10 € cada mes?

Y bueno, ¿qué pasaría si el señor Spotify decide dar otra vuelta de tuerca con las cuentas de sus usuarios? Ya no a nivel de precio, sino a nivel de que, de repente, te das cuenta de que la estructura de listas/carpetas que te has currado tras años, aunque parezca que esté alojada en tu máquina, realmente es una abstracción que vive en la nube del señor Spotify. Como tal, quién te dice que no se sacan de la manga en el futuro, por el motivo que sea, algo así como: “Nuevo tipo de cuenta: si quieres opción de gestionar carpetas, adquiere ya Spotify megamulti! por 15 euros”.

Que no, que de repente, uno le ve las orejas al lobo, y “conmigo que no cuenten” para sus experimentos con gaseosa. Suerte en su cercana e incipiente singladura por EEUU señor Spotify, pero esta vez “no tiene razón”.
Alabo el EXCELENTÍSIMO sistema de listas/carpetas/demás (porque es de auténticos maestros no puedo concebir nada más genial).
Me quejo de la cutrada que es que “no estén ciertos grupos” de manera incomprensible.
Pero a día de hoy, GrooveShark (es lo más parecido a Spotify que conozco, otras sugerencias serán bienvenidas), es donde he abierto una nueva cuenta y donde estoy creando mis nuevas listas poco a poco. Vale que GrooveShark es vía web, vale que no tiene carpetas y la usabilidad “no es tan fresca como la de Spotify”. Vale que cada vez que bajas una canción, aunque la hayas oído antes, vuelve a bajar de nuevo desde internet, entera. (El señor GrooveShark la verdad no sé de dónde saca para pagar tanto ancho de banda).

Pero aun así, Spotify Free/Open va a mutar en algo completamente inútil (para mí y para la mayoría). Y si decidiera cambiar mi cuenta por alguna de las versiones de pago, en mi caso, me hace preguntarme qué estoy pagando exactamente, ya que siempre acabo escuchando “las mismas canciones”, “mis favoritas”, una y otra vez.
Yo no soy un musicófago, ni un melómano, ni nadie con pretensiones de “descubridor de grupos y talentos”.
Soy tan normal como tú.

Tristemente, bye bye, Spotify.

 

Diciembre de 2013 EDIT:  Señor Spotify… ejem: Viene usted a las mías 🙂

_________________________________________________________________________________________

Post to Del.icio.usShare it with Twitter!Menéalo!Like This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized

Creating folders inside Spotify

Jueves, 3/Mar/2011 1 comentario

Some time ago, Spotify added a nice feature to help managing the big amount of lists everyone eventually creates. This feature has a name: Folders.

The utility of these folders is similar to everyday “hard disk folders”, that is “creating a tree structure to manage and keep in place all the songs and lists we’ve added to our Spotify profile”.

How to create a folder? It’s very easy. On the top left part of Spotify main interface, there’s a “+” button, right to our username. If we click it, a small menu appears:

-New Reproduction List
-New Folder

Ok, there it is: “New folder”. Let’s choose this option and create a folder. Let’s name it “hello”.

Once we do it, we’ll see it appear on the left panel, among the already existing lists. And that’s it. No more magic when creating a folder.

What can we do with our brand new and shiny folder? Well, we can just fill it with lists (not songs). How? Dragging, (thus, moving), our songlists onto it. Once we do it, the folder will contains a new song list.

Ok, one could now say that no new functionality has been added if we just put one lists inside a folder, but let’s do something nice: Let’s add more than one list into a folder, (for example, 3 or 4 of them).

Once we do it, we still can click onto these lists (as we did on the old days), and their contents will appear onto the main panel.

But what would it happen if we clicked ON the folder, and not on its individual lists? Well, a big “virtual list” consisting of a merge of the folder lists songs will appear now on Spotify main panel. And that’s the real power of folders: we can crate “thematic” folders like, I don’t know, “Queen”, and then adding different “Queen” lists inside, “Greatest Hits 1”, “Greatest Hits 2”, “Favourites”, “Terrific Queen songs”, etc…
We would still be able to play these individual lists (clicking on them individually), but if we wanted a medley consisting of ALL these Queen songs inside our lists, we would just click onto the folder, and “voi là”, all songs appear properly merged on the main screen, ready to be played by the “Shuffle” engine of Spotify.

Of course, and, as every other folder system in computers, we can create folders inside folders, a.k.a sub folders, and sub sub folders, with no problem. We can also rearrange their structure just dragging their contents up and down, in and out.

But real inspiration came to me the other day, when I was just walking on the street. The bulb lighted and I thought: “What would it happen if I created a MASTER folder from where I could hang ALL my lists, sublists, folders and subfolders?”. And I did precisely that: I created a “root folder” (and I named it “Everything”).

The result has become wonderful, as ALL MY LISTS (the ones I’ve been patiently creating over the last years), as well as ALL the lists I’m also subscribed to (friends’ and such), folders, subfolders, and the rest of my “songs tree”, now appear under “Everything”, properly nested.
Why is it wonderful? Because if I click on the “Everything” folder, on the top part of the screen, a BIG merge of ALL my songs, lists, and folders will start to be played by Spotify.

And for me, and for the rest of people who get quickly tired of listening to the very same music all the time, that’s just pure bliss.

_________________________________________________________________________________________

Dropbox, por qué es imprescindible

Post to Del.icio.usShare it with TwitterLike This!

Categorías:Uncategorized

How to properly crop and resize for maximum crispness in retina screens. It wasn’t so obvious…

Domingo, 27/Feb/2011 Deja un comentario

Since October 2010 I became an Xcode developer, starting to build apps for all the 3 Apple available display sizes as of today: iPad, iPhone “old” and iPhone “new” (retina). The funny thing is, I had 0 experience at all in the mobile development world.

Ok, once you cope with the nice dpi boost in retina screens (as an user), you need also to take care of things you never thought you had to deal with as a coder.

One of these (I thought) obvious things was creating images and contents for the typical iOS on-screen widgets (buttons, labels, etc…). Some may say, “you don’t need to, Cocoa is pretty enough”. Well, for an uncomplicated application, it might be the case, but if your workteam has a GOOD designer, soon you start to spend some time not only coding, but also using your favorite cropping/editing/trimming/resizing program (typically paint.net, gimp, photoshop, etc…) to port his nice and professionally designed interface elements.

When I started trimming images from the shiny designs my coworker created, I somewhat put myself onto “autopilot mode”. That was: You opened the retina master image file (with the full UI on screen), cropped the screen area you wanted, saved it as a @2x version filename, resized the same image file to exactly 50%, then saved it into another file (without the @2x in the filename), and then you took care (just typing it down onto a notebook) of the image dimensions you just created, for a latter usage.

This process shouldn’t be tricky except for quite a common case: Retina buttons you crop from the big UI image, sometimes have odd resolution (here “odd” meaning “not a multiple of 2”).

Imagine you crop a button (in a coarse way), then you refine the crop using some “trim transparent pixels from around the button” tool to just fit the image size to pixels with content (we don’t want to store silly transparent areas surrounding your 24/32 bit png files). Now, look at the new trimmed image size, and type down the resolution you’ve got now (for this article, we’ll suppose our @2x image file measures 157 x 97 pixels).

Then, we might save it to our disk with this filename “some_button@2x.png”. Ok, done.

Now, we need to create the “non-retina” version, for older iPhones, which obviously can only show half the resolution on the same screen area… But wait a moment… The original image resolution wasn’t a multiple of 2, so what does “half” mean in this case? Well, it means “bad news”.
In our case we have to decide which will be our “half resolution”. If the original image was 157 x 97… Half resolution would be 78.5 x 48.5 pixels, but as everyone knows, screen resolutions “don’t have half pixels”, so we have to make an intelligent guess: Do we choose (78 x 48) or (79 x 49)?

Fast answer: Both will give us headaches (in terms of retina display), and I’ll show you why just below.

Anyway, let’s choose the first one and let’s downsize the original retina image (157 x 97) onto a 78 x 48 pixel version. We’ll call it “some_button.png”.

In terms of image quality, when downsizing, we NEVER have to worry (no matter the resolution), because we’re losing resolution no matter what we do. IT’S NOT OUR PROBLEM (today). We should anyway use interpolation, and then our half sized image will be recreated from the bigger resolution one, yielding more than satisfactory results. We would have a problem if we were doing it the other way back: upsizing from low-resolution to high-resolution… But that’s not the case.

OK, right now, we have the 2 necessary versions: “some_button@2x.png” (157 x 97) and “some_button.png” (78 x 48). Now we should import BOTH files inside XCode. Then, when we launch Interface Builder, our new image button appears as a the “named resource” “some_button.png”, ready to be used.
One of the nice things about this process, is that even we imported both PNG files into XCode, we only have to use the “non-retina” filename inside our source files. Why? Because the one dealing with the “which version of the file should I choose” question will be iOS runtime, once our code gets executed on the physical device (iPhone, iPad, iPhone-retina). And even more: all this stuff gets transparently done without our intervention.

In more detail, if iOS detects it’s been run inside a retina iPhone, it automagically chooses to show the @2x version of our image, even in our code we just wrote something like: load my image named “some_button.png” (without the @2x) part.
Ok, once we’ve roughly described how iOS deals with retina images, our problems might start now:

iOS runtime image manager is able to pick high resolution images for being used on the render process, BUT iOS screen resolution, at least “logically” is not 640 x 940 (the new dpi boosted one), but 320 x 480, the “crappy” and old iPhone3 one… That is, in Interface Builder we DESIGN our UI with non-retina resolution, expecting that in runtime, iOS-retina will deal with the pixel doubling process.

And what does it have to do with our image files? Well, here comes the funny part.
I said we were forced to choose among 2 “wrong” resolutions. In our first example, I said: “lets choose the 78 x 48 version”.

If we do that, iOS will build a 78 x 48 container on screen, which will be filled with the 78 x 48 version of our “some_button.png” file. So far so good: our low resolution button gets 100% perfectly shown on screen, no distortion, no nothing. Just crisp pixels (reduced, but crisp).
But if we run the very same code on a retina display, the logical container size will be 78 x 48 (as I said, that is iPhone 3 size), BUT this container will be doubled before rendering anything into it. So our logical 78 x 48 container becomes a physical 156 x 96 container, once it appears onto the retina screen. And now, that’s the point where our @2x file (157 x 97) gets rendered onto the actual screen pixels, inside this 156 x 96 container. And as you might think, yes, this creates UGLY resampling of our image, even the rendering process is only shrinking our image file by just a mere pixel.
One might say: “really? is it SO ugly to the eye?” Without any doubt I say, YES! and I invite you to do the test.
(TO DO: I’ll create a demo webpage to show all this in the near future).

So, first option, downsizing to half size -0.5 pixels was a bad choice. Let’s see what happens if we take the +0.5 pixels version for our “non-retina” file size: 79 x 49 (of course, keeping the retina file size 157 x 97, as it was/is the original resolution our designer created for our button).

If we do ALL the process again, we arrive to the very same conclusion, that is:
-Our non-retina container will now be 79 x 49 pixels.
-Our physical retina container on screen will measure 158 x 98 (doubling the size of the logical container, 79 x 49), and again our big file in disk is still 157 x 97, and then when iOS retina places the image into the container, it will suffer a resample of 1 pixel bigger in both directions: Result? Visual distortion again, and our beautiful and crisp button becomes absurdly blurry.

So, is there a solution for all this? Yes it is (probably more than one), but the one I like most is thinking a bit BEFORE SAVING our first @2x retina image file:
-Instead of just blindly saving it, we should check its canvas size, and we will INCREASE ALL DIMENSIONS (width and/or height) SHOWING odd numbers. In our example, our 157 x 97 file will be upgraded onto a 158 x 98 file, JUST ADDING a row and a column of transparent pixels (on the right and bottom sides of it for example).

Will it visually interfere? Not really, (assuming we’re using PNG-32/24 files), because transparent pixels, as its name say, are transparent.

OK, the second half of my “workaround”, just after having saved the @2x version of our retina button, is halving our new image dimensions to achieve half the resolution with no decimal numbers. In our case we get a 79 x 49 small file. One might say: “hey, that’s the same than the second choice of the wrong examples you showed us”. Well, “yes”, resolution is the same, but built up from a different (1 pixel bigger) master file. If you compare carefully, even resolution is the same, contents won’t.

Are we done yet? Absolutely.

We only need to update our Interface Builder UIButton/UIImageView dimensions container, setting it to 79 x 49.
That’s it? Yes it is. Because whenever iOS retina will render this button on our live application, it will create a (79 x 49) x 2 container size, that is 158 x 98, and now our carefully created @2x image file will EXACTLY match this resolution, rendering a sharp and crisp 1:1 image file with the contents of the @2x some_button.png file we carefully created.

I hope my explanation is kind of understandable, I’m open to corrections and suggestions, so feel free to ask.
I just wanted to write all this personal experience, hoping people will be able to create proper image buttons from day 1, and not from day 100, as it happened to me 🙂

NOTE: This method I described, is 100% valid also if you want to create “universal mobile web pages”. That means, “with the same .html file you create both normal and high resolution webpages at once”. Safari under iPhone retina will treat ALL measurements as “low resolution”, except for image files. Feed your webpage with “high resolution” images only, and you’re done (your low resolution webpage version will resample bigger resolution images on runtime).
BTW, I’ve made some preliminary tests on my own, and even Android high resolution display devices treat document dimensions as “low-res”, even image files can be “high-res”, so you kill many birds with just one stone.

Greetings

Post to Del.icio.usShare it on TwitterLike This!

Dropbox, por qué es imprescindible

Categorías:Uncategorized