The idea of having a widget to do marketing for a game didn't work much; after joining MochiAds to get some revenue from my games, the thing was going a bit slow... I still haven't lost my hopes on using widgets to do some marketing though but definitely the way to go is to distribute your applications EVERYWHERE. For the last year I've been building widgets and uploading them into different distributors, trying not to upload the same widget to more than one distributor; however I don't think it was the best option. The more distributors show your widget, the more users... Now, going back to the game "La Cucaracha", I decided to send it to some game distributors, including NewGrounds, where the game did so so and I had some views that generated some small profit (around $1 :D )... A couple of days ago, I got and email from MindJolt telling me that they had accepted my game and after a small amend should go live; I did the changes and the game went live yesterday and... HURRAY!!!! I had almost 50K views in one day only! the reason? MindJolt has a really cool Facebook application where people are encouraged to play games and compete with their friends to see who has the highest score...
GREAT! that encourages me to keep on developing games, although I shouldn't leave widgets on a side, so the next one will be a game widget! :D
Roaches is a widget I built some time ago and put it on yourminis but didn't think it will be successful at all, however seems like its a bit popular as so far has more than 1200 installs.
I've made some minor updates as the cockroaches were a bit slow but the biggest reason for the update (and for this post) is because this widget has now a new purpose: Marketing. I've added a small "play game" button as a "call to action" to any person watching at the widget; the widget itself has some sort of interactivity as the cockroaches react to the mouse pointer, but I'm promoting the update of La Cucaracha, a game I made long time ago and these days I've been working on it (but haven't managed to upload the latest update as I cannot connect to my server... :( ) Anyway, here it is:
Might be a bit naughty from me adding something to a widget that has been in the wild for a while but at the end of the day, as soon as my widget doesn't have any sponsor, I'm its owner and I can do the changes I want (changes that won't change much the nature of the widget though). erm... this of sponsors sounds more like in the gaming industry as when you build a game, you can go to online companies that can buy it from you or sponsor it in any way; I think we are missing this in the widget industry.
Anyway, yes, I'm back to the gaming industry as from last month I started a new job as a Flash Developer for an Online Games company in Central London. As well I moved houses and I haven't got internet at home yet, that's why this blog has been a bit quit these weeks...
The event is on Thursday December 6th in the sunny and trendy city of Brighton and if I managed to convince my new managers (I'm changing jobs next month), I'll be there for sure.
Taking part in the Blog Action Day I will talk about this subject that is related to Digital Media and to the environment as well: Screensavers. Screens. Many people tend to confuse the terms and end up calling "screens" to their monitors (the hardware); screen is part of the monitor, only where the software is projected or displayed and this one shows data as pixels for us, human, to understand.
What pixels show is actually light. This is basic Digital Media colours theory where each pixel shows a combination of Reds, Greens and Blues (RGB) and when their value riches 256 (100% for humans) then is white light.
When there's absence of colours, there's absence of light; this will led us to believe that: the less light, the less power your monitor spends.*(wrong statement!)
A screensaver is a computer program designed to prevent a "Phosphor burn-in" on a CRT and plasma computer monitors by blanking the screen or filling it with moving images or patterns when the computer was not in use.
If you check the screensavers that that come by default in your windows (I haven't checked the Mac ones...), you will notice that all of them have a black background.
screensaver = saves your screen *(again, wrong statement!)
Now, what should we take into account when building screensavers? - Something important from the Wikipedia's Screensaver definition is that they mentioned CRT monitors and these work in a different way as the TFT-LCD monitors that most of us use nowadays. * Wikipedia:
Monitors running screensavers consume the same amount of power as when running normally, which can be anywhere from a few watts for small LCD monitors to several hundred for large plasma displays. Most modern computers can be set to switch the monitor into a lower power mode, blanking the screen altogether. A power saving mode for monitors is usually part of the power management options supported in most modern operating systems, though it must also be supported by the computer hardware and monitor itself.
Additionally, using a screensaver with a flat panel or LCD screen instead of powering down the screen can actually reduce the lifetime of the display, since the fluorescent backlight remains lit and ages faster than it would if the screen was turned off completely. As fluorescent tubes age they grow progressively dimmer, and they can be expensive or difficult to replace. A typical LCD screen loses about 50% of its brightness during a normal product lifetime, if left on continuously. (In most cases, the tube is an integral part of the LCD and the entire assembly needs to be replaced.)
Thus the term "screen saver" is, in most cases, a misnomer--the best way to save the screen (and also save electricity) would simply be to have the computer turn off the monitor
. So, I would recommend: - Check who your target is and depending on that, consider (or not) designing a clean and clear screensaver, avoiding a black background. Remember, those screensavers made by Microsoft for its Operative System, where made some years ago, when most of the people had CRT monitors. - Be careful with the animations, definitely use them but don't abuse them. It's not good to have all the elements in the screensaver jumping from side to side as that can become annoying. - Avoid using sound. - Don't worry much about the file size as you would for a web application. - Use vector graphics as you don't know the screen resolution of the final user if in case you would allow the graphics to be scaled (up or down) or if you want to use a fixed size for your animations, then consider a plain background colour as there might be people using really high resolutions that will want to use the screensaver. If in case you have chosen to have a fixed size, then you can use bitmaps as they wont get pixelated and consider optimize the graphics for 800x600 pixels resolution as in the latest web browser statistics, there's a still big 14% of users with this screen resolution.
If you think of anything else that should be taken into account, please add it in the comments. And remember, the best way to save energy is turning off the monitor, so if you leave your desk for more than 5 minutes, just press that button ;)
more info: http://en.wikipedia.org/wiki/Screensaver
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:
Web Widgets vs Desktop Widgets - Subject It 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.
- Usability When 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. - Dimensions Even 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. - Size Not 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. - Shape I 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? :D For 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 touches Adding 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 options When 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.
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:
The widget shows the latest visitors statistics from your blog or website, collecting the data from Clicky and showing the top 7 of a respective category. The available options to show are:
- visitors top cities - incoming links - search engines - downloads - operative systems - visitors top countries - entrance pages - web browsers - search keywords - exit pages - pages - searches - languages - screen resolutions - incoming link domains - outgoing links
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.
Alex Iskold has a very interesting post on the subject (How javascript is slowing down the internet...) and after reading it, I got rid of some widgets as an attempt to speed up the loading time of this blog but it is still slow.
Today I was reading a post from Derek Anderson and his frustration on the matter (Fricken widgets keep disappearing) and I absolutely agree on what he says. Lawrence Coburn at Sexy widget wrote something related and how he realized it after one of his readers comment.
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.
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.
The steps to follow are: - Sign up if not already a user
- click on the Submit a Widget button
- Fill in the form
- Choose the platform and browse for your widget (in this case is a standalone widget for windows)
- Click submit and you should see the message "Your widget was successfully updated." and that's it, your widget should be the first one in the gallery and the distribution will start...
Check out the "pie clock" desktop edition that I just uploaded.
So now you know, for desktop widget distribution, Widgipedia is the way to go.
I've written another tutorial about Building desktop widgets; I had explained before why I'm using MDM Zinc and what I've done with it so far.
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!
If you followed my previous tutorial, go and check this one out as after it you will have a desktop widget ready to distribute.
I have just uploaded a widget to Widgipedia called "Subscrbe to my feed", erm... I know, the name is not that nice but I'm not that creative to put names to my widgets :P This is the description from Widgipedia:
Replace that old RSS button for this cool Flash button to promote your feed and allow your viewers to subscribe to your site with ease. Just put this widget into your blog (or any other page with a feed) and flash will do the rest.
Technically speaking, via javascript-actionscript it gets the URL where is embedded into and sends it to a php, this php searches through the html of the page and returns the RSS (if any), then is easier for the user to add your feed to any reader.
The original design was made by UtomBox and you can find it here, and this is the way it looks:
Subscribe to my feed
Click on the "get" button to grab it and embed it into your blog and of course, click on the widget itself to add my feed to your reader ;)
It was about a year ago that I started playing with small flash applications that later on evolved to "widgets". As I didn't know they were actually widgets, I called them "buttons" and offered an embed script to my readers so they could use them; the first one was "add to delicious flash button" and I offered many more after that one (and many people still use them!) It was until December 2006 that I discovered Widgetbox and decided to register my widgets over there for a better distribution. There are many advantages on registering widgets with any distributor, for example, more people will see them therefore more people will use them; usually distributors have a "comments" system so you can get feedback from your widgets users and feedback is one of the most important things when developing any application as it allows you to see what is good and what can be improved.
As you might now, there are many widget distributors around and is up to you where you want to register your widgets, but I would like to tell you my thoughts: - Even though Google Gadgets offer money to their top developers, I wouldn't advise you to register a widget with them as it's not easy, there's no promotion, no proper statistics, and your widget will be completely lost in the wild... - Clearspring it supposed to be the top distributor in the galaxy that has served billions of widgets but to be honest I had a very bad experience with them as the only widget I've submitted has few visits and seems like no-one is using it...
So, for web widgets distribution I recommend you three different sites: - Widgetbox - Widigipedia - Yourminis Each of these websites have their pros and cons but from the ones that I've tried they are the best for widgets distribution.
Now let's see how easy it is to register a widget on one of these sites, this time I've chosen Widgetbox. From Widgetbox site, these are the benefits of registering flash widgets with them:
No-paste installation into MySpace and other sites. Users can install into MySpace and TypePad without cutting and pasting. More platforms are coming soon.
MySpace linking. We enable your widget to link out of MySpace.
User configuration of Flash. Allow bloggers and other subscribers to configure your widget. This actually changes the generated <embed> tag. Users get a live preview of their changes as they make them.
In addition, Flash developers get everything we offer all widgets, such as:
Widget Syndication Metrics. Track the spread of your widget across the internet with your own widget analytics dashboard. Learn more.
Viral adoption. Widgetbox provides a simple, direct mechanism for people that see a widget in the wild to get it for themselves.
The first thing you would need to do is to register yourself with them (link at the top right of the page). Then follow this link to register your widget. - Select "Register an existing remote service as widget" - Fill in the first form (yes, I'm afraid this is one of the bad things about Widgetbox, to register a widget there are many steps to follow... ) - When you click next you will get to the widget configuration page where you can add different options to your widget so it will be customizable. One parameter you might want to add is the wmode= transparent. Please check the Flash Widget developer guide to find out more about this parameter and other options. - Click next to preview your widget; if you don't want your widget to be resized then tick the related option. Bear in mind people like to customize the widgets as much as possible. - When you are happy with your widget look, click next to fill in the final form (uh! at last! well, not quite...) This is the most difficult bit as you will need to think categories, tags, summary, description and upload a picture of your widget for the gallery. I will advice you to have ready a 96x96 pixels png thumbnail of your widgets best view. When you have finished filling in the form, press save widget and you will get message similar to:
If you are thinking "when is this guy going to finish speaking about 'building flash web widgets'"? well, I still have got two more things to talk about (sorry, I know I said that before...), but my idea is to write as much as possible so you have a better understanding about "best practices" when building widgets ;)
This time is about managing the "right click" from the mouse and this is considered best practice in any web application, not only on widgets. Best practice? why do we need to care? well, you never know what a users is going to do with your application and is better to prevent possible bugs testing whatever is possible to do. For instance, whenever I'm checking someone else's work, I'm always using the right click to zoom-in to their applications, press play, etcetera as I'm very curious and want to know if the developer cares about details; trust me it makes a difference.
The first thing we need to do is to get rid of the "built-in items", yes, the same from the picture above, and to do so we need only one line of code:
Stage.showMenu = false;
Adding that simple line helps us to avoid the user to do something we didn't want him/her to do like pressing "rewind" or "play" (if using more than one frame). I normally use one only frame so the right click menu doesn't show some options but still it shows the "zoom-in", "quality" & "print" among others. However, with this line of code we won't be able to get rid of all the items, for example the "about adobe flash player 9..." as is part of the "copyright" from Adobe.
And talking about copyrights, can we add our own copyright or something like that? certainly we can and the way to do so is with the following actionscript in the first frame:
function linkToMe():Void { getURL("http://overloadstudios.blogspot.com/"); } function linkToDistributor():Void { getURL("http://www.widgetbox.com"); } var cmMenu:ContextMenu = new ContextMenu(); cmMenu.hideBuiltInItems(); cmMenu.customItems.push(new ContextMenuItem("Built by Overload Studios", linkToMe)); cmMenu.customItems.push(new ContextMenuItem("Powered by widgetbox", linkToDistributor)); this.menu = cmMenu;
We won't need the Stage.showMenu = false; anymore as with this code we are hiding the "traditional" menu. What we have are two functions to link to this blog and to the widget distributor, in this case Widgetbox. Then we are instantiating the class "ContextMenu", hiding the "built in items" and adding two items to the new "array" of items. The last line is to tell flash which menu should show. You can add more items if you want to or remove one or the other, but remember to add this right click menu to all your widgets to allow users to know who built the widget and to visit your website; this is a nice way to show that you are the developer and not with a cheese roll over banner as other people do. :P
I remember when I started "blogging" I decided not to add any sort of adds as I thought they looked bad, they wouldn't add any good to my blog and anyway I didn't have many visits... nowadays I've got some more visits (more than a couple of thousands monthly) and even though I still think adds look bad, after reading so many stories about people who make money from them I decided to give them a try so I could pay a proper server to host all my experiments and make more interesting stuff mixing more technologies (PHP - MySQL - Flash) because at the moment I've got a very basic account without access to a database and millions of .txt files for some of my widgets users to store specific data (ie counters).
For about two months or so I tried an affiliate program and added some banners to the blog expecting some of my readers will click on them and buy some stuff... It happened that they clicked on the banners a couple of times but never bought anything, I guess it was because they where about UK based companies and most of my visitors are from other places.
Today I've decided to say goodbye to these "sponsors" as I didn't get any penny from them :D and I'm only leaving the old and worse looking Google adSense.
With that one is another story, I added it a couple of months ago and still don't understand why it shows some funny adds, not related at all with what I write about... I remember about a couple of weeks ago when I was about to say goodbye to them as well, someone clicked on one of the links and I got my first $0.15, then I decided to leave them, I don't know how long for as so far I have earned less than $0.50! :D
Well, anyway, affiliate programs are not for me, the banners where really annoying so I'm happy I got rid of them :)
So far I have uploaded widgets to three different sites: - Widgetbox - Widgipedia - Yourminis and I must say that the first time I uploaded a widget to any of these three sites it was not an easy task but not something out of this world, these three distributors are doing their best to help any developer to publish their widgets with ease, some of them have more steps, other ask for more information, but the requirements are not really a big deal. However, Google Gadgets is different cup of tea. After reading many different pages from its documentation I still haven't managed to find out how to allow users to change settings to a flash widget; the documentation is just too big and complicated, many pages with many links that don't give precise answers or at least I couldn't find them... I gave up trying to upload the clock from my previous post as it has some options to change the colours so I had to upload another experiment just as a test; after following their instructions and building a not too friendly xml file, I managed to upload a widget:
I still couldn't see if its in their library as whenever I look for its address I only get this error:
Sorry, http://hosting.gmodules.com/ig/gadgets/file/113526947643047156725/analoguecalendar.xml is unavailable. Please try another result.
well, maybe another day I will continue reading the dozens of documentation pages and I will manage to upload other widgets...
There was something missing from my previous series of posts "Building flash web widgets" that I want to talk about, in fact there are three things I want to add:
The code in AS3 - I haven't yet written a single line of actionscript 3 as both at home and at the office I'm still using Flash 8 but Felix Sanchez has re-written the code into actionscript 3 so please check it out if you are already using Flash CS3 or an alternative tool to publish Flash Player 9.
Customization - As I said before, I have changed the design so its clearer for the user to understand and I have added something very important for web widgets: customizable colours. Customization in one of the most important bits of a widget if in case you want it to be successful and popular, this is something I had to learn from trial and error as at the beginning I didn't think about giving more options to the users and their complains taught me the lesson... Tip: add as many customizable options as you can because nowadays the web is very users centric and users want to show their own style and taste in their websites.
and what's the difference? well, now when changing from second to second, minute to minute and hour to hour, the change is more smooth and when reaching the limit, either 12 or 60, there's a very nice animation when they go back to the origin (the centre of the widget). Oh lovely tweener! :D
in the same line of code we are managing width, height and calling the next function. I think is cool, that's why I like tweener so much.
and the final widget:
That's using the same code but different design so now is you changing the design and getting your widget ready to upload to a widgets distributor (That I will explain in a future post)
Thanks for the award! :) And by the way, if you need inspiration or just want to see some cool stuff, go to the MashupAwards and check out the daily & monthly winners.
There are many tools out there to check out your website's statistics and most of them offer you the same options, however, Clicky has something that really makes checking statistics an addiction: the Clicky spy. Of course my website doesn't have the traffic Clicky does but still I can check in real time who's visiting me and what my visitors are doing... It's really cool to see how my visitors jump from page to page internally and click on external links, etc.
Another cool thing is that Clicky has its own API so developers can play with it an create widgets or similar stuff and these days they are running a contest for widgets developers; of course I've submitted a widget that I hope I will be using here as soon as the guys at Clicky allow me (I guess until they decide the contest winners, the submitted widgets should remain "hidden").
with this code we are telling flash to change seconds_mc width and height to a bigger number every 1000 milliseconds (1 second), and if we test the movie, in fact seconds_mc grows every second. The problem is that it doesn't stop growing, so let's add some more code:
function removeSeconds():Void { seconds_mc._width = 6; seconds_mc._height = 6; }
function checkSeconds():Void { if(seconds>59){ seconds = 0; removeSeconds(); } }
timer = setInterval(attachSecond, 1000);
In our function "attachSecond" we are calling "checkSeconds" to see whether the cycle has been completed and we have already 60 seconds, if so, we call removeSeconds to resize seconds_mc to 6 pixels that we decided to have (in the previous tutorial) instead of a 0 (zero) to see something on the stage. Then we should attach another minute:
if we test our movie, it should work fine and the clock should be ok, adding minutes and/or hours when adequate. The whole code looks as follows:
var timer:Number; var timedate:Date = new Date(); var realHours = timedate.getHours(); var hour:Number = (realHours<=12) ? realHours : realHours-12; var minutes:Number = timedate.getMinutes(); var seconds:Number = timedate.getSeconds(); delete timedate;
As a good practice, we have declared the variable timer at the beginning so flash knows that the variable exists and which sort of variable is. Then is up to you to add more stuff, for example tweenings, changing design, etc. and don't forget to add something to help "reading" the clock, for example the cross I drew in mine showing numbers from 1 to 12 and from 10 to 60 so the users will have an idea about the time... and basically that's it! you have a clock working 100% and you can now upload it to any widget distributor like widgipedia, widgetbox or yourminis. One of these days I will post a clock I'm working on using the same code but different design to give you an idea of what you can actually do.
This is the second part of the series "building flash web widgets", click here to see the first part. Ok, I've done my homework and I know how my clock is going to look like, of course in the meantime I will continue explaining how to build something similar to the clock in Part I. Now that we have the time showing in the output window, we need to translate that into objects on the stage.
- From the menu, go to insert>timeline>layer to add another layer and rename it "elements"
- Press select the oval tool pressing "o" and draw an circle on the stage, the size is not important but has to be symmetric, mine is 25x25 pixels, and is better if it has no stroke so it won't look strange if at different size. Select the circle and go to modify>convert to symbol (or press F8) to convert it to a movieclip and call it "circle_mc".
- Select the instance of circle_mc you have on the stage and write "hours_mc" as its instance name and change its alpha value to 90.
- Add two more instances of circle_mc to the stage, one will be called "minutes_mc" and the one on top will be "seconds_mc"; minutes_mc will have an alpha value of 60 and seconds_mc will have an alpha value of 30. We need to align all the elements to the centre of the stage.
- Now the code. Lets add the following lines to the actioncript we already have:
What we are telling flash is, the width and height of each instance it will change depending on the value of the related variables. Minutes and seconds are multiplied by 3 and hours are multiplied by 15. why? ok, let's see the maths: - The idea is that the circles grow as much as 180 pixels so they will still be visible on the stage, as each minute has 60 seconds, then we divide 180 by 60 that give us 3 so the seconds will be different to one another by 3 pixels in size. Same for minutes. Now, hours is different as there are only 12 hours per cycle, so we divide our 180 pixels by 12 and that is 15, so every 15 pixels there will be one hour. But there is something I don't like; how about if the hours and minutes are 0 (zero)? visually will not be nice as the stage will be almost empty... As we still have space to complete our 200 pixels, let's add 6 pixels to each value:
So, the idea of this "series" of tutorials is to build a flash widget and upload it into a widget platform for the world to see, use, rate & you become famous as I did... :D (I'm joking, ok?)
I will not ask you to build the basic "hello world" as I would prefer to go much further than that, even though we will build a basic widget: a clock; but we will use the time units in a more creative way and we will build something like:
I assume you have Macromedia Flash 8 (or Adobe Flash CS3) installed and you are familiar with it.
Let's start:
- Create a new flash document and change its properties going to modify>document or pressing control+j (apple+j if in Mac), the new dimensions should be 200 width & 200 height, however, its better if your widget is even smaller; change its frame rate to 24fps and click ok.
- Our stage is empty and we have only one frame; rename that frame "actionscript" and lock it as we don't want anything else on that layer, just our actionscript (best practices, you see)
- Select the first frame (the only one we will use, best practices...) and add the following code:
var timedate:Date = new Date(); var realHours = timedate.getHours(); var minutes:Number = timedate.getMinutes(); var seconds:Number = timedate.getSeconds();
Press control+enter to test your movie and you should see something like 22:44:38 in the output window and it is the actual time as taken from your computer's system. What we are doing is: - instantiating the date object in a variable called timedate. - calling three different methods of the date object to get the hours, minutes and seconds and storing the values in three different variables: realHours, minutes & seconds. - deleting the date object instance as its not needed any more so we clean it from the memory (best practices...) - with trace we tell the output window to show us what the variables have stored.
ok, we now know how late it is, but, to be honest, I don't like that of "22 hours" as its sounds to military for me and I'm used to see 10pm instead of 22 hrs... so, let's change the code:
var timedate:Date = new Date(); var realHours = timedate.getHours(); var hour:Number; if (realHours<=12) { hour = realHours; } else { hour = realHours-12; } var minutes:Number = timedate.getMinutes(); var seconds:Number = timedate.getSeconds();
Similar idea, we have just added a new variable: hour and its value depends on realHours value, using a conditional we are sure not to use the 22hrs format but a more understandable one (and better for this example). Testing our movie, we should have something like 10:45:14.
Actually, the code looks a bit too messy; having a conditional in the middle of the way doesn't look that good, but good job there is a short cut for that conditional, so, we change the code again:
var timedate:Date = new Date(); var realHours = timedate.getHours(); var hour:Number = (realHours<=12) ? realHours : realHours-12; var minutes:Number = timedate.getMinutes(); var seconds:Number = timedate.getSeconds();
It's exactly the same, just a different syntax that I find cleaner. If you test your movie, your output window should show you something like 10:50:11.
Well, I'm afraid that's it for today; I've got to do some house work now but we will continue soon. In the meantime, think about your design, read more about the date object and see you later.
Last weekend I was experimenting a bit more with different ways to display the time, again working with clocks using Tweener and a bit of Maths and this is one of the widgets I did, the Radial Clock has similar idea to my Squares Clock but tweening the time units in a radial way similar to an analogue clock. I've used the ChangeColour AS2 class to show the rollOver state of a button that links to this blog.
Radial Clock
As you can see, this time I've added it to the yourminis website, and it's the first widget I've uploaded over there. To my surprise, few hours later, the clock had been cloned! of course immediately I wrote an email to yourminis letting them know about it... later on I realized that "cloning" widgets is actually a feature in the yourminis platform called "remix".
I'm a bit jealous with my widgets and didn't find it funny though... :P
Well, it was interesting trying a new widget platform, maybe another day I will write something about my experience using the different platforms I've used so far.
salut!
// --- Edit ---
It seems like yourminis doesn't exist any more. The widget shown here is powered by Widgipedia.
I made this class some time ago and I'm still using it whenever I don't have time or creativity to do any other rollOver - rollOut effect; One of my readers (who saw the Spanish-Polish application) asked me about it so, why not sharing the code?
I guess these days I would do it in a different way but still does the job; to use it, just copy and paste the following code into your actionscript editor and save it as ChangeColour.as
/* * * Version 1 * * Movieclip rollOver and rollOut ChangeColour class * * Author: Ernesto Quezada, Overloadstudios (ernesto.quezada(a)gmail.com) * Date: October 2006 * * Description: Gradually changes colour and brightness to a movieclip when rolled over * and back to its original colour when rolled out * */ class ChangeColour extends MovieClip {
private var control:Number = -10; private var addShine:Object; private var currentState:String; private var myColour:Color;
// -- Events -- private function onRollOver():Void { currentState = "rolledOver"; this.onEnterFrame = function () { checkState(); }; } private function onRollOut():Void { currentState = "rolledOut"; }
// -- private functions -- private function checkState():Void { myColour = new Color(this); myColour.setTransform(addShine); if (currentState == "rolledOver") { if (control<=100) { control += 10; addShine = {rb:control, gb:control-20, bb:control-50}; } else { addShine = {rb:0, gb:0, bb:0}; } myColour.setTransform(addShine); updateAfterEvent(); } else if (currentState == "rolledOut") { if (control>=10) { control -= 10; addShine = {rb:control, gb:control, bb:control}; } else { delete this.onEnterFrame; } myColour.setTransform(addShine); updateAfterEvent(); } } }
Then put it in a folder called Classes (or wherever your classpath points to) and whenever you want to use it, in the Flash library, right click on a movieclip, select export for actionscript and write ChangeColour as the AS 2.0 class.
I know, I made it 9 months ago and needs a review...
A year ago I posted something about a Spanish-Polish application I was working on as part of the experiments and personal stuff I was doing in my spare time. Let's see an update on what I mentioned in that post: - I managed to finish just 2 out of the 3 games I was working on (Breakout & Blitzkrieg) - The Spanish-Polish application is still half way, those designs where put into flash but still there's a lot to do. Only 3 out of 8 sections are working: Time, Calendar & Colours but still need sound. Click here if you want to check it out.
And, what am I working on these days? - 3 widgets - if I have time, I might continue with the Spanish-Polish application...
I'm a bit obsessed about data, I think of data as numbers because every single piece of data represents already a unit! For example, when I built the CPU Usage widget, I translated the numbers into bars, tweening depending on the data; same when I built the Moving Earth widget, where the magnitude of earthquakes is shown using bars as well... But if we take numbers and translate them into squares, so X units will be represented by squares, then we have something like my Firefox Screensaver or the Squares Clock widget:
As is experimental then expect some minor bugs :P If you like it, you can get it from Widgetbox.
Trying out FeedBurner I noticed most of my feed readers are using either iGoogle or Google Reader, products I knew about but never took a close look at them. I assume many other people are using this two ways to check news on many blogs without going to each blog each time... so I built this Add to Google flash button widget and uploaded it to Widgipedia, this is the description:
Promote your feed by placing this widget to your website. This will make it easy for people to quickly add your feed right to their Google homepage or Google Reader.
and this is how it looks like:
To be honest it wasn't that easy to build as there is some crazy php coding behind to get the HTML code from the page that displays the widget, search through it looking for the feed address and as soon as it locates the feed, sends this address to Google...
I hope people find it useful and if you think of a similar widget I should built, just shout ;)
The other day I asked my mate ThatBlokeMike which Tween class was he using, the answer: Rob Penner's one, included by default when you install Flash. I talked to him about the goodness of Tweener & how it helped me to speed up my developing process, but still couldn't convince him... That's why I've decided to have a look at both options and see why I prefer using Tweener rather than Tween.
When I first started "Tweening with Actionscript", I was checking every time a great tutorial on Kirupa about it: Using the Tween Class.
It was good at the beginning, in fact I used it for several months and was happy about it, but still had to go back to Kirupa to check the options; the reason: the code needed to do a simple tween is a bit too long...
For instance, if we want to blur a Movieclip on an OnMouseDown event, if using the Tween class, we will need to import the the Tween class, the Filter class, play a bit and after writing a long code and spent some good minutes doing it, we will get what we want. But, if using Tweener, with a couple of lines of code we will get the same effect! Click anywhere on the flash movie:
of course, it has some "back downs" but is up to you if you consider them "too bad", anyway, after using Tweener for some months now, I've found just two of them: - It doesn't (yet) have anything similar to the "yoyo();" method found in the original Tween Class. - It adds to your final swf 5 or 6kb more than if you were using the Tween Class only. for me, that's not a big deal, so my advice:
Download Tweener, try it out, if you like it, keep on using it, if not, don't use it and all of us happy :)
To celebrate it, I've changed the look & feel of this blog. To be honest, it wasn't easy because Blogger is not as flexible as other blog platforms but hey! I like it! :)
I just hope I can manage to have some free time to experiment more with Flash, build more widgets, games & write some more tutorials...
