Thursday, September 6, 2012

Phone Call screen in Windows Phone

   I've wanted to write this post for quite a while but I've always postponed it as it is a very subjective matter. In the end I decided to write my opinion. Windows Phone is really great but there are some aspects that could be improved and seem that have been designed in a hurry and never finished. One of this aspects, and it is not what this post is about, is the Application List. It is ugly and not very usable. How is it possible that Windows Mobile had before anyone else folders/groups but they are still missing in Windows Phone after more than 2 years? The application list really needs improvements/redesign.
    This post instead is about the Phone call screen. I've have always had problems with my windows phone devices starting with the Omnia 7 and ending with my Lumia 800 (I've actually tried 3 different Lumia 800 all of them gave me the same problem). The short story is that I am able to drop the call with my face by pressing the Endcall button, put the call on speaker, put it on mute or hold. I am not the only person that has these problems: my wife has the same problem with her new Lumia 710 and also heard from other people. It is a combination between the proximity sensor that activates the screen and the way I am holding the phone. So I've wondered if maybe there is a better location for the Endcall button.
    Lets start with a photo I've found on the web  (have no idea who she is) :
If you look at the way she is holding her phone (which I think is 90% of the cases) the upper part of the screen is in contact with the face. Let's presume that by a faulty behavior (bad driver, hardware fault, OS fault or the fact that the hardware and the software are not designed by the same company) the screen turns on while you talk. The highest probability to touch the screen with the face is in the upper half of the screen. Let's see what it means in Windows Phone:
So it is Endcall, Speaker, Hold, and Mute (exactly my case).

If you look again at the picture you can see that the less exposed part of the touchscreen(so the better choice for the buttons location)  is the lower part of the screen. The lower you go the smaller the probability is, so the best choice for the End call button is the lower part of the screen (this way you minimize the probability to press the button on faulty behavior). This is exactly (I don't know if this is the reason) what iPhone and Android did:
Both of them have chosen to put the End call button near the lower part of the touch screen. For Android (which also depends on the hardware implementation) Google concentrated all the buttons at the lower part of the screen. On the iPhone they kept the other buttons in the center region but they do have really good control over the hardware and putting a call on hold or mute is not as bad as dropping the call.
So it would be better to move the buttons in the lower part of the screen. The blank space could be filled with social information, last call, email, sms. 
Hope we will see some improvements in Phone Call screen in Windows Phone 8

Tuesday, September 4, 2012

What MediaLibrary needs/is missing (Windows Phone)

      As we (average developers :) ) still don’t have access to the Windows Phone 8 SDK I decided to write a post on the current MediaLibrary limitations for Windows Phone. I only hope that someone from the team will read this post and maybe there is still time to improve some aspects in the new version. Everything here is my personal  opinion.

So what is missing from the MediaLibrary?

1.     The Token property exposed on the Picture object

The most important for me. Why? Let’s open Internet Explorer on the emulator and go on a webpage that has a picture in it, tap-n-hold and save it twice. If we use Windows Phone commands to launch the Pictures hub in the emulator and go to the Saved pictures album we will see both pictures (same picture but different items). Now let’s create a new project and see what we can get using the MediaLibrary class. I will use this simple code to debug and stop on the pictures to watch its properties:

MediaLibrary ml = new MediaLibrary();
//MediaPlayer.Queue.ToString(); ;
var albums = ml.RootPictureAlbum.Albums;
foreach (var album in albums)
if (album.Pictures.Count>0)
foreach(Picture pct in album.Pictures)
bool stophere = true;

We can see both pictures but the BIG problem is that the only way to differentiate between the two of them is the Date property (not very elegant, Handle is not public property). The Token property  makes a lot of sense to tell which picture is which (maybe also a Path member could be added but Token is way better as we already have the method to open a picture from its Token and you won't have to iterate all the MediaLibrary just to get the picture we want).

This property should be fairly easy to add as it already exists internally (when we use the PhotoChooser we will get the token associated with the selected picture and we will be able to open the picture) . 

The token could be extended also to the PictureAlbum class. It doesn’t make much sense to iterate the MediaLibrary to find a specific album if I already know what PictureAlbum I want.

2.     The possibility to create new picture albums

In this moment the Pictures Hub already has built-in albums but it is not possible to create new albums directly from the phone. It is possible to do it from Zune (which will not be used anymore) but it is not a trivial task (at least till you understand how it works). So we are mainly stuck with two “containers”: Camera Roll and Saved Pictures which is not enough for a device that theoretically could hold up more than 1GB of photos. From here the need to have tools to organize your photos better by creating new albums and copying/moving photos between albums. Maybe it is a little late to implement it in the "standard" WP8 UI as we are two months away from the official launch of the first phones on the market but maybe not too late to add the functionality in the development tools so the developers can implement it in their apps. This way a photo app could create its album and then the users will know in which album to look when they want to find pictures modified/created by a certain app.

3.     Access to the videos on the device

Needed since the first version of windows phone but still no sign of it. Videos are an important part of the device media and developers need access to this part of the MediaLibrary to enable applications like video processing, video backup, video creation and more.

4.     Make the Favorites Pictures album work

This functionality already exists in the Windows Phone Mango/Tango but it doesn’t work in the current version of the SDK. I’ve already posted a question on the forum with no answer till now. The count of the Favorites album is always 0.

5.     Enable MediaLibrary access in the background task

Useful for applications that want to backup the pictures from the device automatically. If it’s a problem of security see 6 but if the user already agreed at some point (capabilities, ask permission) it doesn’t make sense to lock the access to the medialibrary from the background tasks.

6.    Security/capabilities

I think the current ID_CAP_MEDIALIB  is too generic. It would be better to have specific CAP for pictures, videos and songs. They are pretty distinctive and a photo editor wouldn't need access to the songs on the device? Also the user should be warned that his photos might contain GPS data in the EXIF header and he should agree to let the application access those informations.

P.S. Almost all of the features requested are already implemented in the iOS development tools.