Archive for April, 2010
books vs. ipad
Apr 19th
I commented this, but I think it is relevant to how we design for screen.
http://craigmod.com/journal/ipad_and_books/
The most interesting part of the article is about content.. Formless content and Definite content..
how do they relate, and how do you take the content we are familiar with in books, and translate it (the same content) in a way that is it understood in a new medium? but so it works for that medium to it’s full advantage..
“in the context of the book as an object, the key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries. Whereas Definite Content is not only aware of the page, but embraces it. It edits, shifts and resizes itself to fit the page. In a sense, Definite Content approaches the page as a canvas — something with dimensions and limitations — and leverages these attributes to both elevate the object and the content to a more complete whole.
Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas. Formless content is usually only text. Definite content usually has some visual elements along with text.”
the ipad totally shifts the idea, is it easier to read a book on screen?
you make your own opinion.
Fontstruct
Apr 19th
http://fontstruct.fontshop.com/faq
I think everyone interested in type should get an account. I have already found so many sweet typefaces, played around with the actual tool to inspire my application, and it seriously connects you to so many avenues… criticism, processes, downloads, tutorials ..etc
FontStruct is a free online font-building tool, devised and developed forFontShop International by Rob Meek.
The heart of FontStruct is the FontStructor, a web-application that lets anyone quickly and easily build fonts using basic geometric shapes in a grid — just like tiles or bricks. Fonts created with the FontStructor are called FontStructions. They can be downloaded as TrueType fonts and used in Mac or Windows applications.
More than a tool, FontStruct is a vibrant online type-design community. Type-design enthusiasts from all over the world use the FontStructor to experiment with letter shapes and to design fonts, and who give each other comments online on the FontStruct website. They are the FontStructors, the soul of FontStruct.
For non-FontStructors, FontStruct is a source of fresh fonts available under flexible, liberal CreativeCommons licenses.
Finally, for educators, FontStruct is an ideal environment to teach the basics of type design. The brick principle and the simplified, easy-to-use interface of the FontStructor help students to overcome the complexity inherent to type-design and focus on the most important aspects first
App Project: Evaluations
Apr 19th
Download pdf of App Project Evaluation form
Everyone will receive an email invitation to an interactive pdf form. You will be asked to fill out the evaluation form for each project (using Adobe Acrobat reader) and submit the evaluation back to me.
The evaluation includes analytical and holistic criteria:
Students will evaluate their peers’ projects based on the analytical criteria.
T-Mobile participants will evaluate the projects based on the holistic criteria.
After I compile the evaluations, each student will receive a graphic representation of their project evaluations as well as the raw data from each reviewer (reviewer names will be anonymous).
Download pdf of mock data compilation
App Project: Final Presentations
Apr 19th
Arrive at 10am
Tuesday, April 27
to load ALL presentations
onto one computer.
(Bagels will be served)
FILE FORMAT:
gd492_lastName_appPresentation.swf
1024 x 768
PRESENTATION FORMAT:
9 minutes presentation
3 minutes Q&A
2 minutes to finish evaluation and transition
ORDER OF PRESENTATIONS:
April 27
10:15 : Caitlin Atteberry
10:29 : Leah Lawrence
10:43 : Nick Romanos
10:57 : Logan Sayles
11:11 : Dave Maki
11:25 : Jonathan Stephens
11:39 : Betsy Sherertz
11:53 : Sam Cox
April 29
10:15 : Betsy Peters
10:29 : Lauren Hall
10:43 : Jen Edwards
10:57 : Alex McNeilly
11:11 : Christina Hardison
11:25 : Madiha Malik
11:39 : Riley Huston
The iPad and screen real estate.
Apr 18th
Flash demo : tween with code
Apr 13th
To learn more about TweenMax and TweenLite, go to
To learn about the flash transition class
Draw a rectangle the size of the screen (240 x 380px) on the stage.
Convert the rectangle to an mc named “box”.
Double click on the mc to get to the box timeline.
Create a new layer named “button”.
Draw a rectangle and convert it to a button named “circle_btn”.
Name the instance of the button “circle_btn” in the properties inspector.
Go back to the main timeline and name the instance of the box on the stage “box” in the properties inspector.
Create a new layer named “actions” and paste the following code in the actions palette:
import com.greensock.*;
import com.greensock.easing.*;
// ————VARIABLES——————————————–
//object position variables
var xPos:Number = stage.stageWidth / 2;
var yPos:Number = stage.stageHeight / 2;
// ————ADD OBJECT TO STAGE———————————-
/*
//add child to stage variables
var box:MovieClip = new box_mc();
//add the movieclip from the library to the stage
addChild (box);
*/
// ————SET INITIAL STAGE POSITIONS——————————————–
//object name and postion (refer to position variables above)
box.x = xPos;
box.y = yPos;
// ————LISTENER AND FUNCTION FOR CLICK ON BOX——————————————–
box.circle_btn.addEventListener(MouseEvent.CLICK, onCircleClick);
function onCircleClick (event:Event):void{
//add tween for box currently on stage
TweenMax.to(box, 1, {x:-120, y:yPos, alpha:1, ease:Circ.easeOut, delay:.15});
}
Flash Demo : drag and drop objects
Apr 13th
Drag the same pink and black box mc’s from the previous demo onto the stage.
Name them “box_gray” and “box_pink” respectively.
Create a new layer named “actions” and paste the following code into the actions palette:
box_gray.addEventListener(MouseEvent.MOUSE_DOWN, dragGray);
box_gray.addEventListener(MouseEvent.MOUSE_UP, dropGray);
box_pink.addEventListener(MouseEvent.MOUSE_DOWN, dragPink);
box_pink.addEventListener(MouseEvent.MOUSE_UP, dropPink);
//box_gray.addEventListener(Event.ENTER_FRAME, enterGray);
box_pink.addEventListener(Event.ENTER_FRAME, hit);
function dragGray (event:MouseEvent) : void {
event.target.startDrag();
}
function dropGray (event:MouseEvent) : void {
event.target.stopDrag();
}
function dragPink (event:MouseEvent) : void {
event.target.startDrag();
}
function dropPink (event:MouseEvent) : void {
event.target.stopDrag();
}
function hit (event:Event) : void {
if (box_pink.hitTestObject(box_gray)) {
box_gray.alpha = .25;
} else {
box_gray.alpha = 1;
}
}
Flash demo : add and remove child from stage
Apr 13th
Create a pink box on the stage and convert it to an mc named “box_pink”. Before clicking okay, check the radio button to “export for Actionscript”.
Create a black box on the stage and convert it to an mc named “box_black”. Before clicking okay, check the radio button to “export for Actionscript”.
Delete both instances from the stage.
Select the first keyframe in the timeline and paste the following code into the actions panel:
var boxBlk:MovieClip = new box_black();
var boxPink:MovieClip = new box_pink();
var xPos = stage.stageWidth / 2;
var yPos = stage.stageHeight / 2;
boxBlk.x = xPos;
boxBlk.y = yPos;
boxPink.x = 120;
boxPink.y = 150;
addChild (boxBlk);
boxBlk.addEventListener(MouseEvent.CLICK, onBlackClick);
boxPink.addEventListener(MouseEvent.CLICK, onPinkClick);
function onBlackClick (event:MouseEvent) : void {
removeChild (boxBlk);
addChild (boxPink);
}
function onPinkClick (event:MouseEvent) : void {
addChild (boxBlk);
removeChild (boxPink);
}
Flash Demo : animate with code
Apr 13th
Create a box on the stage and convert it to a movieClip named “box”.
Name the instance of the mc “box” using the properties inspector.
Create a new layer named “actions” and paste the following code into the actions panel:
//add child to stage variables
var box:MovieClip = new box_mc();
//add the movieclip from the library to the stage
//addChild (box);
//position box on stage
box.x = stage.stageWidth / 2;
box.y = stage.stageHeight / 2;
//scale and transparency box
box.scaleX = .25;
box.scaleY = 1;
box.alpha = .1;
//enter frame listener and function to animate when movie begins
box.addEventListener (Event.ENTER_FRAME, animate);
function animate (event:Event) : void {
event.target.scaleX += .01;
event.target.scaleY -= .01;
event.target.alpha += .05;
event.target.rotation += .5;
}
Apple takes aim at Adobe… or Android?
Apr 9th
Apple takes aim at Adobe… or Android?
By Peter Bright | Last updated about 4 hours ago
The already strict requirements that must be met for an application to be published on Apple’s App Store are set to take a turn for the worse, as Apple’s NDA-protected license agreement has now updated an already annoying existing clause, Section 3.3.1, to make it even more offensive.
The original clause stated:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
This clause has already frustrated developers in the past because there are tasks that developers would like to perform that can only be achieved through private APIs; though some have taken a risk and submitted applications that use such APIs, the result is often that the application is denied. The new version of 3.3.1 reads:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Things just got a whole lot more restrictive for iPhone developers. What this change means is that developers can no longer use software like Novell’s MonoTouch, Unity3D, or Ansca’s Corona to develop iPhone applications, and tools like Appcelerator’s Titanium and PhoneGap are looking questionable. MonoTouch, Unity3D, and Corona allow developers to use the C# language and Lua scripting, respectively, to write iPhone applications. Titanium and PhoneGap allow application development using JavaScript and HTML; because they use WebKit behind the scenes to run that JavaScript, they might be OK.
The reasons that developers like and use these tools are many and varied. Titanium, PhoneGap, and Corona, in particular, offer rapid iPhone development environments that are simpler than the Cocoa and Objective-C environments used for native development. As such, they offer their users quicker, more responsive release cycles, and lower development costs. Unity3D provides a range of features to game developers like a 3D engine, a physics processing engine, audio processing, and so on—features that would be prohibitively expensive for most developers to write from scratch. MonoTouch more simply allows the use of a different programming language and different libraries, ones that certain developers might be more comfortable with.
A significant product that is soon to be added to this list of development tools is Adobe’s Flash CS5.
The real enemy: Adobe
As is now well-known, Flash isn’t supported on the iPhone (the license conditions prohibit that kind of runtime application), so in response, Adobe has given Flash CS5 the ability to produce iPhone applications, in a broadly similar manner to how the other tools work. As Adobe explains, Flash CS5 completely skips Objective-C, instead plumbing into the iPhone compiler to directly produce executable code.
Apple’s seething dislike for Adobe has become increasingly apparent in recent years. It’s a dislike that in many ways makes no real sense: most of Adobe’s biggest products don’t compete with Apple’s (and vice versa), and using Adobe’s applications has traditionally been one of the biggest reasons that people have chosen—and stuck with—Apple’s platform. But that’s all in the past; Apple has Flash in its sights and is doing its best to destroy it.
Adobe, for its part, has made some non-commital comments on the issue; the company still plans to ship Flash CS5, but its ability to create iPhone applications might turn out to be short-lived, to say the least.
Apple’s new 3.3.1 restrictions have been met with some disdain from the developer community, too, and it’s no surprise. After all, if followed literally, they’d prevent developers even from writing English language specifications for their programs—since such applications would not be originally written in one of the blessed languages! A case could be made that the rule change prevents even thinking or talking about iPhone programs. Of course, the App Store gatekeepers will not be quite so absurd, but there’s certainly ample scope for inconsistent application of the rules. Nothing new there, unfortunately.
The other real enemy: Google
As well as hurting Adobe, and certainly tarnishing the company’s brand new product, this move hurts Android. In fact, I think the harm done to Android could end up being even more substantial than the harm to Adobe. Although I would say that the biggest virtues of these banned tools are faster, easier development, the fact is that they also often encourage cross-platform development. Flash is perhaps the most obvious example of this, but MonoTouch, Unity3D, and Titanium all enable developers to write applications that are more easily ported to non-Apple platforms such as Windows and Android. Such conversion is not necessarily automatic—applications will typically need some amount of tailoring to adapt them to the different environments—but it’s a big help.
Minority platforms are always going to be the biggest beneficiaries of cross-platform development. It might be hard to justify developing an application for a minority platform from scratch. But if I can take a program for the majority platform and then put in an extra 10% development effort to cover the minority too, that’s a much more appealing prospect. Though Apple does not dominate the smartphone market taken as a whole (Symbian is the runaway leader, with RIM’s BlackBerry in second place), I think it’s clear that in the narrower market of, shall we say, mobile phone-computers, Apple is the leader. Symbian and BlackBerry devices are all too often relegated to being little more than phones with e-mail, and though applications can be developed for both, they have not inspired developers and users in the way that iPhone and Android have.
No real defense
Some observers strive to justify this decision by claiming it’s better for Apple’s users, because in their world all cross-platform apps are bad, so they’re better off without. It’s true that cross-platform apps often buck platform UI conventions, and so end up feeling kind of alien—available on lots of platforms, but not really fitting properly on any of them (as anyone who’s had the misfortune to use iTunes on Window will testify). But it’s not as though being platform-specific is some guarantee of quality. There are plenty of lousy natively-written iPhone applications out there, and these are often produced in a cookie-cutter fashion, so that they can be churned out en masse. In contrast, there are also lots of good cross-platform programs out there.
Nowhere is this more apparent than in the world of gaming. Games are in many ways a class of their own, because games generally offer unique user interfaces: interfaces that are tailored to the game, rather than leveraging the platform. And there are certainly a lot of developers out there producing high quality, popular games using tools like Flash. This idea that cross-platform applications will be bad, such that Apple’s users are better off without them, just isn’t universally true.
Yes, some cross-platform applications will be bad. Some native applications will be bad, too. The reasonable, equitable solution is not to ban the use of tools that produce cross-platform applications. It’s to say “applications must conform to all appropriate user-interface guidelines” and ban any application that doesn’t. This is something the company is already doing anyway, and something that’s unlikely to be a big issue. The existing development toolkits for iPhone make it easier to produce cross-platform applications, but certainly don’t enable the kind of Write Once Run Anywhere approach that Java once promised. They just enable developers to migrate the “working parts” of their applications from one platform to another. The all-important user interfaces will still need to be customized to the needs of the different mobile OSes.
No, this policy change can’t be attributed to a desire to ensure the quality of the user experience. It’s about control. Developers must choose to target iPhone explicitly, or not at all. Apple doesn’t want anyone to even consider writing applications for other platforms, and is going to stand in the way of anyone trying to do so.
Open hostility
Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple’s Xcode doesn’t. Sometimes it’s just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn’t just hurt competitors. It hurts developers on Apple’s platform, and in turn hurts the platform itself.
The absurdity of this is even more apparent if one thinks back to the initial announcemnt of the iPhone. The iPhone was never going to have an SDK. The mantra was “use web applications”. Indeed, that was one of the driving forces behind Apple’s creation of a first-rate mobile browser. Since the browser was going to be the application platform on iPhone, it had to be good. And indeed it was. The company was reluctant to produce an SDK; this was not simply a case of managing expectations, and keeping quiet about the SDK until it was good and ready. It was a sincere desire to use the web as the development platform. The eventual decision to release an SDK caught many within the company by surprise.
Web apps are still an option, of course, for developers willing to live with their inherent restrictions. For those who can stick with C and C++ for the majority of their development, some level of compatibility between iPhone and other platforms is still possible. But both options still fail to give the considerable benefits that the third-party development platforms provide.
Apple’s current—and in our opinion, objectionable—position is now close to the complete opposite of its initial stance. From promoting openness and standards, the company is now pushing for an ever more locked-down and restricted platform. It’s bad for competition, it’s bad for developers, and it’s bad for consumers. I hope that there will be enough of a backlash that the company is forced to reconsider, but with the draw of all those millions of iPhone (and now, iPad) customers, I fear that Apple’s developers will, perhaps with some reluctance, just accept the restriction and do whatever Cupertino demands.
