Sunday, September 30, 2007

The way I'm learning things, specially about building widgets, is from trial and error. This is not the best way to learn as it's better to prevent than to cure but as I don't have enough time to read and study about the subject and because this is just a hobby for me, I just do the things as I think they will work but after finding the "errors" I realize there are many things that can be done in a better way.

It's not that I'm new on the subject (building widgets) but it's my nature, I love experimenting, I love finding out how to do things in a different way and I love using my creativity when doing stuff.

So, the series I wrote about "Building flash web widgets" are WRONG! not because the script doesn't work nor because other technical issues but because of some basic aspects I didn't take into account when I built the widgets.

This is a review of those posts about building widgets and the final product:Get great free widgets at Widgetbox!

Web Widgets vs Desktop Widgets- SubjectIt might sound obvious but web and desktop are two very different worlds and even though there are many people out there trying to merge both worlds, bringing the web to the desktop and vice versa, web and desktop are still very different from each other, desktop is personal, web is open to the world.Desktop widgets interact more with your system and with the data that comes from it, being this a CPU usage, space left in the hard drive, etcetera, things no-one else cares about but only you. Web widgets interact more with web users showing visitors statistics, countdowns for different events, music you like, and other things you definitely want to share with other people.How about building a clock as I did for the tutorials on building widgets?It works for both web and desktop, it's a common subject but the concept should be treated in a different way: keep it simple for the web and for the desktop, it can be simple or it can be interesting & complex as well.

- UsabilityWhen we are on-line we want the information to be displayed now, we want to understand what it's going on ASAP, therefore, showing an experimental clock where the user has to think to understand what the time is just DOESN'T WORK.

How do I know that?Well, just check out the pathetic statistics; after more than a month out there, the clock has not even 30 subscriptions. On the other hand, we are used to admire the desktop and its applications, we can open any widget and take our time to check it out, we love playing with it, dragging it, changing colours checking the different options, and if we don't like it just drag it to the recycle bin and that's it...More than 500 downloads in less than a month tells me that.- DimensionsEven though your web widget can be displayed in many different environments, most of them and in most of the cases, they will be displayed in the sidebar of a blog; remember that nowadays not only my aunt but hers cat has a blog and even if it's not the rule, your widget will end up in a sidebar's blog.As mentioned in this post, the "Pie Clock" is 200 by 200 pixels and that is TOO BIG for any sidebar.I would recommend any size from 100 to 180 pixels width and depending on the concept/design, from 50 to 300 pixels height. I would say, 180x300 pixels is just the perfect size, however, this depends on the subject-concept-design. Take into account that Google adds some extra pixels to the sides of your widget (b*stards! :D ) as you can see on this breakout-mini widget that just looks AWFUL.- SizeNot the dimensions but the size of the application itself, known as well as weight, in bytes.Might seem to be obvious but as we are used to develop things for the web, we tend to optimize all the graphics for the web.In fact, when building web widgets, we SHOULD optimize for the web all the graphics and our widget should not be bigger than 50kb (that is already BIG!), however, that again depends on the concept. Remember that people will have more than one widget and we should think about the loading time of a website and how important it is for users (when a site takes to long to load, people tend to close it and visit the next one...)When building for the desktop, the graphics should look really good, we don't need to optimize them and we can add all the necessary stuff using the best possible quality as users don't care about how big a downloadable file is; of course, we don't have to abuse, I would say from 2 to 3MB file size would be fine.- ShapeI know I want to be as creative as possible, I want to break the usual square and my widget should have crazy shapes everywhere. Well, if we are using Google Gadgets to distribute our web widgets, that won't be the case, Google adds an ugly box around the widget with an opaque background so our web widgets will look like in a prison that doesn't let them "breathe" (graphically speaking). Did I called them b*stards before? :DFor desktop widgets its different, we can have nice shapes, of course, we shouldn't abuse nor we should have transparent octopus shapes everywhere, keep it simple but break the square box.

- Final touchesAdding nice animations and transitions is essential for an eye catching widget, of course being careful not to reach the limit from nice to cheesy.The advantage for web widgets is that the whole widget can have an animation, it can move from side to side, change shape, etcetera, but desktop widgets, specially with exotic shapes, request a lot from the processor when moving on the stage. Another thing to add is an extra menu using the right button of the mouse, read this post for web widgets and this post for desktop widgets.Something I'm considering is adding a "read me" .txt file attached to the desktop widgets where I can explain how to use the widget and other documentation.

- Extra optionsWhen adding customization options to the web widgets, the options are usually available only when first selecting and installing the widget. Could be great if the web widgets would have a better way to update this customization options when already installed. I'm not quite sure but Clearspring allows you to update this options when the widget is already in use, I remember having read something about it when adding one of their widgets on my blog. Desktop widgets usually have the option to change settings at any time, that's a great thing and a big advantage from desktop widgets over web widgets.

Sunday, September 16, 2007

This is the "widget version" of the Breakout game I did some time ago.I submitted it to Google Gadgets and I must said, it was again a big pain! I really thought that it will be easy this time but no way, finding the right page to do all the things its a nightmare, creating the elements and editing the xml file is another big headache...Anyway, here it is:

Sunday, September 09, 2007

So far, no one has yet set the rules in this crazy widgets world and now we are suffering the consequences. Different distributors use different options, tools, scripts, approaches, etcetera and none of them seem to be compatible with each other.

Even though from November last year the World Wide Web Consortium already listed a document about widgets, there's still something wrong about the web widgets ecosystem.

Definitely we need to do something about it.Now, that us (widget developers) need to monetize to have decent servers, it's definitely true!My stuff is hosted in a very dodgy server and I've asked for help to some widget distributors without any positive answer. At the end of the day, I don't get anything from my widgets but they do and they should help us out.

There are some distributors that host the widgets themselves and that's fine as I don't need to worry about my dodgy server, however, sometimes their server is slow as hell so I have got rid of 5 cool widgets hosted in their server as you never know when their server will go slow again (affecting my site).

Now let's see how the process works:- As an internet user I visit your page and this one starts loading. The speed depends on my machine, my internet connection and YOUR SERVER (where your site is hosted).- If you have widgets, the first request goes to THE WIDGET DISTRIBUTOR'S SERVER- as soon as the distributors javascript file has loaded, this pulls the widget and it comes the third request: WIDGET DEVELOPER'S SERVER.- how about if the widget triggers some info from a web service? and if it's a mash-up? more servers involved...- It's very likely you will have more than one widget (specially if you blog about widgets) and the more widgets distributors involved, the more requests to different servers, the longer your page will take to load...kaput!

There are far too many steps, requests, etcetera and what happens is, your page is taking ages to load and I don't want to wait so I leave your site...

Solution: get rid of all other widgets but mine! :D ok ok, that's not a solution...I think the problem is very complex, distributors and developers need to find a solution together, the developers need more support from the distributors, otherwise this crazy widgets world will collapse soon.

Saturday, September 08, 2007

I have already written something about the distribution of web widgets but if we are talking about distributing desktop widgets, the approach should be a bit different.

If you have built a Mac Dashboard widget, definitely you would need to submit it to Apple Dashboard, however, you shouldn't leave the things there and should submit it to a different distributor as well, in this case I would recommend you Widgipedia.In fact, Widgipedia is the only distributor that accepts any sort of widgets, from web widgets to Mobile widgets and of course desktop widgets so if you have followed my tutorials on Building desktop widgets with Zinc and right click on desktop widgets, the following step is the distribution.

Something I like the most about submitting widgets at Widgipedia is that your widgets don't need to be accepted and approved by any person so as soon as you have finished filling in the form and click "submit" your widget will be available for distribution. Great!and to make the things even easier, the form to submit a widget to Widgipedia is unbelievable simple.

Sunday, September 02, 2007

On this new tutorial you will see a bit of the {mdm}Script and a bit more of actionscript as I mention another feature of the ContextMenu class that used before in my post Building flash web widgets: Right click.

I must say there's lots of potential in Zinc, just have a quick look at its documentation and you will know what I mean, specially the {mdm}Script 2.0 API; there are many options from database connectivity to socket communication but the best of it is the support forum where people like Peter Blazejewicz are happy to help you out. I mentioned Peter because his willing to help is just impressive!