For every project you should check your skills before you start. It helps a lot for preventing possible problems and makes the life easier. Thus I highly recommend to do a self-assessment before your start as a Flash Independent Developer. After this self-assessment you should have a very clear picture about your abilities, skills and of course your weaknesses. It is very important that you know your weaknesses because you can outsource some of this problems to your network buddies. An independent team-oriented working approach works in this case very well, because it replaces your weakness with a strength of another person. It works like the Captain Planet or the A-Team metaphor 😉
Skills-Mindmap Flash Independent Developer
On the mindmap you can see the 4 core skills: Design, general knowledge about New Media, Programming (Computer Science) and soft skills. As an employee it is not so important that you have skills in each of these core skills, but as an Independent Developer you have to be an allrounder. gSkinner wrote a nice post about the must-have qualifications as a Flash Developer. I would like to add the points doing project management and creating networks to this list. An (Flash) Independent Developer has to be fancy to do project management tasks and get in touch with other people. If you don't like it, then you should not become an (Flash) Independent Developer! But I think the completely different charakter of the tasks make the life of an (Flash) Independent Developer so much more interesting. Read more...
A couple of months ago I started thinking about becoming an Independent (Flash) Developer. So I wrote a blog series in German about this topic. This blog series describes my idea behind the passion of an Independent (Flash) developer. Unfortunately, the feedback was quite less for me and zproxy is right, when he said I should write this in English because of the less size of German speaking flash developers and that it is also an interesting subject for all English speaking flash developer... So I decided to translate all my articles about this subject in English. Who is able to read German can have a look on the complete series here.
Firstly, before I started any activity into this direction of becoming an Independent (Flash) Developer, I had to define my personal idea of an Independet (Flash) Developer.
So my main goal is to do cool things with Flash or other Technologies, which I really enjoy to realize. That could be a Flash Game, or an open source library for a special problem or just a nice software or anything, what you can imagine.
After this process of creation I must have a product, which brings some money in my pocket, so that I am able to pay my rent and living costs. So the most important thing for me is that this product has a relation to things I love to do! The earning or the income plays minor role. I hope when you do cool things the money will come...
In addition to this, I thought freelancing could be the solution. Do some small projects, which are ok for me and spend the rest of my time with the cool things I would like to do... But later I noticed for me that is not the freedom I want to have. So I spent more and more time to find a nice solution and I think I found a plan which could work. I am going to tell you the details in this blog series about the passions and opportunities of an Independent (Flash) Developer.
Comparing the job opportunities
The information size of my solution is too big for one blog article, so I divided it in 10 parts. Every part explains a very important part of the Independent (Flash) Developers journey. I created a Mindmap for you which shows all subjects and relation beyond my blog series I am going to mention. Read more...
I have already mentioned it in an earlier blog post that I am still working on a vimeo component for the Adobe AIR environment. Now I have created version which is stable enough for a intensive testings. So if you would like to use it for your Air Application, don't hesitate to use it. I would be very happy about some feedback messages from you.
Now I describe some special functionality compared to my FlexVimeo Player component. Because of the incompatible command Security.allowDomain() in the Adobe Air environment (which is essential for working with the Vimeo Moogaloop API ), I had to create a seperate remote player. This remote player receives control message and send control messages via LocalConnection to the AirVimeoPlayer Component. So if you use my AirVimeoPlayer Component, you must always use my remote_vimeo.swf File for controlling the Vimeo Moogaloop API. It works in the same way as the youTube AS3 API Wrapper.
The other not so nice thing is that I ran in some perfomance issue because of sending to many messages via LocalConnection. So I had to put down the amount of update message for the PlayingState.Playing, but that should not be problem for you. In my cases it works fine.
Die letzte Runde im Projekt Masterstudium ist erreicht. Alle Bewerbungsbedingungen und Aufnahmeprüfungen habe ich mehr oder weniger erfolgreich absolviert, und die Ergebnisse sind nun auch schon alle eingetroffen. Erste Wahl war eigentlich dieFH Potsdam, danach dasHPI in Potsdam. Das lag zu einem an deren beidem guten Hochschul Ruf und an der sehr facettenreichen Stadt Berlin zum Wohnen. Leider fand ich die Aufnahmeprüfung an der FH Potsdam nicht so cool, und die ganze Kommunikation rund um die Bewerbung war mir nicht wirklich sympathisch. Daher ist es vielleicht sogar gut, dass ich von der FH Potsdam eine Absage bekommen habe und auch vom HPI... Mit diesen Absagen war Berlin für mich erledigt, und es blieb mir noch die Kunstuni in Linz und die Uni Konstanz übrig. Da fiel mir die Entscheidung am Ende nicht mehr so schwer. Da ich über mehrere Wochen hinweg ein gutes Bauchgefühl von der Kunstuni in Linz hatte.
More than 2 years ago I wrote a blog post about Flash Game Programming. Since this blog post until today a lot of actions happens in the Flash Game Community. Some Flash Game Developer created great classes, libraries and frameworks, which makes our life as a Flash Game Developer so much simpler. In this blog post I would like to give a short overview which tools are available at the moment.
General Frameworks & Classes
In this category you can find tools, which solve some common problems like resource management, loading processes, screen management, level management and so on
Last time I worked a little with the Moogaloop JavaScript API, because I thought it would be a nice workaround solution for integrate the Moogaloop API in an Adobe AIR Application. First time I tried the example code from the vimeo api documentation and it worked fine on my webserver. But for my case I did not want to use the SWIFF JavaScript Code. Only the SWFObject Code for embedding Flash Content in HTML was for me o.k. So I spent a few hours to get this API work without this SWIFF JavaScript thing. I tried a lot, failed a lot, cried a lot and laughed a lot about myself and my limited JavaScript knowledge. So now I am happy with my current version, because it works fine without this SWIFF thing, except loading a new Video (or should I say loading a new clipID) into this SWF Container failed. So if anyone has an idea, please post a comment here!
I was very happy after completing my extended VimeoPlayer Class, so happy that I had enough motivation to wrote a Flex Component. With my component it is now very easy to use the moogaloop API in Flex. The functionality features are the same as my VimeoPlayer class, except that I also support some Flex-based features (Data-Binding, updatedRendering).
I created a very ugly and simple Flex GUI Interface, which demonstrates the functionality of this Flex Component. The component has some useful attributes / properties and some Functions. Here a short overview:
FlexVimeoPlayer Properties:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Bindable]publicvideoClipID:int;// The vimeo video clip id
The API functions to control the vimeo player api are still the same, except the setSize() Function is not available anymore. You can use the width and height properties of the component as every other Flex Component. Here are the available functions: Read more...
The last weeks I dealt with the vimeo Moogaloop API. The documentation on the JavaScript and Flash API was not so well. But fortunately a couple days ago they updated the documentation for the JavaScript API and then for the Flash API. So now I am able to give an introduction how you can use the Moogaloop API in Flash. The guys from vimeo published a Videowrapper Class which handles the very very basic stuff of the vimeo video player. So you can easily import the vimeo video player in your Flash Projects and you are able to do basic functionality like play(), pause() and loading a new video. But if you wanted to create your own video player, this wrapper class doesnot go too far. So I did some analysis on the moogaloop.swf File and found some interesting functions, that solves some of the problems, which Robert Abramski described in his Blog post Vimeo Player and the Secret API.
In my blog post I will describe how you can use my extended version of the VimeoWrapper class. For a deeper inside of the analysis I will write another blog post. So here you can see the my “ugly vimeo Custom Player” as an example application.
A short explanation of the control buttons. Beginning with the left button :
Play Button -> Play the vimeo video
Pause Button -> Pause the vimeo video
Blue Seek Button -> jump to a defined position at the video
“C” Button -> Change the color of the vimeo video controls
“V” Button -> Loading a new Video
“F” Button -> Resize the vimeo video and the player (Fullscreen Mode)
“M” Button -> Mute the video sound
“U” Button -> Unload the vimeo video and stop the loading process
“Q” Button -> destroy the VimeoPlayer Wrapper Class
Between the video and the controls you can see the duration and the currentTime of the Video and the VideoStatus of the File. Read more...
Einfachheit bzw. Simplicity war im Jahre 2006 auf der Ars Electronica und allgemein in der Interaktionsbranche das Topthema schlechthin, natürlich erschien auch das Buch Laws of Simplicity von John Maeda in diesem Jahr. John Maeda hat seinen Ursprung im Design und Kreativbereich und versucht in seinem Buch Laws of Simplicity die kleinsten gemeinsamen Faktoren für das Geheimnis der Einfachheit zu finden. Er hält sich dabei so allgemein wie möglich um die gewonnen Erkenntnisse für jeden Themenbereich zugänglich zu machen. Dabei kommen leider desöfteren unglücklich, esoterisch klingende Formulierungen zustande, die in mir eine gewisse Skepsis hervorgerufen haben. Ich denke, das ist auch Grund der sehr unterschiedlichen Meinungen im Web über dieses Buch. Dennoch muss man diesem Buch zugestehen, die gefundenen Faktoren bzw. Laws of Simplicity sind sehr gut ausgewählt und lassen sich super für den User Experience Bereich nutzen. So kann man wirklich fast jedem Gesetz einer Teildisziplin der User Experience zuordnen:
Reduce -> Interface und Produkt Design
Organize -> Information Architecture und Navigation Design
Time -> Interaction Design – Visual Design / Interaction Patterns
Learn -> Interaction Design / Interaction Pattern
Differences -> Marketing, Features Cultures
Context -> User Experience allgemein
Emotion -> Branding
Trust -> Security (Geschäftspolitik)
Failure -> Interaction Design, Usability
Combination of all Laws
Im Gesamten finde ich dieses Buch nicht unbedingt ein Must-Read. Es fasst gut zusammen und beschreibt die Faktoren der Einfachheit sehr schön an Beispielen. So dass man einen guten ersten Eindruck in die Thematik bekommt, die dann für weitere Diskussionen anregen kann. Mit seinen knapp 100 Seiten und dem sehr praktischen Taschenbuchformat lässt sich dieses Buch sehr gut auf einer längeren Zug- oder Flugreise lesen. Wer also Langeweile haben sollte, dem sei dieses Buch empfohlen. Ansonsten gibt es vielleicht auf meinem Bookstore ein passenderes Werk…
die kleinsten gemeinsamen Faktoren für das Geheimnis der Einfachheit zu finden. Er hält sich dabei so allgemein wie möglich um die gewonnen Erkenntnisse für jeden Themenbereich zugänglich zu machen. Dabei kommen leider desöfteren unglücklich, esoterisch klingende Formulierungen zustande, die in mir eine gewisse Skepsis hervorgerufen haben. Ich denke, das ist auch Grund der sehr unterschiedlichen Meinungen im Web über dieses Buch. Dennoch muss man diesem Buch zugestehen, die gefundenen Faktoren bzw. Laws of Simplicity sind sehr gut ausgewählt und lassen sich super für den User Experience Bereich nutzen. So kann man wirklich fast jedem Gesetz einer Teildisziplin der User Experience zuordnen: