A New Work-Week Schedule
by jay
We’re trying a little something new at JLOOP.
Even though we’re a pretty standard 9-6 business in a lot of ways, in a lot of other ways, we’re not. Our work involves routine processes and daily tasks, but we are also a creative firm – and creative work sometimes doesn’t happen on schedules.
So we’ve been pondering for a long time whether some periodic changes in our work-week schedules might be a good idea. And we’ve decided to give it a try.
For the time-being (meaning, we don’t know for exactly how long we will implement this change), we are closed to the outside world on Fridays. We are doing a few different things with this time. Some of our team will be working 4-day weeks for a while, and some of us will be here on Fridays – either working intently on client services, or… surprise, surprise… working intently on our own projects. (pique your interest?).
Of course if there is ever anything urgent, you can always reach us at support [at] jloop [dot] com.
We’ll keep you posted on how this new schedule affects our productivity and our creative output. We’re interested to find out ourselves!
Flash’s short term/long term problem
by jay
So where does Flash go from here?
I’ve been thinking a good bit about the predicament for Flash and it isn’t pretty.
I’ve been building Flash websites and applications for 10 years now. I started right at the time when Flash 5 was arriving (I never really used TellTarget much, thank goodness). When I really got going building Flash stuff, I would say it felt “hot”. There was no end of inquiries and the ability to make stuff move around on screen made people pretty giddy.
But what turned my Flash skills into a career was the fact that there was an overload of terrible Flash hitting the web. The fact that Flash was so “easy” to produce, made every web shop around think they should use it, just because they could. For this reason, Flash got a pretty bad name in a lot of circles. But as I’ve always said, it isn’t the tool’s fault, its the untrained artists who were using it. In any case… it created a nice landscape for me to stand out, so that worked well for a good long time. It was exciting.
Platforms a-plenty
Cut to today. JLOOP produces web applications of all shapes and sizes. And Flash has become only one component of what we do. We still produce full-Flash websites, and Flash is used to some degree in almost every project we work on. The main difference here is that we never ever utilize Flash without providing an alternative. With tools like SWFObject, it is so easy to provide a non-flash alternative in a seamless way… there really is no excuse not to. Of course it gets more complicated when you are doing full-Flash websites, but the onus is still on us to provide a reasonable experience for users across the many platforms there are in use now.
Which brings me to the real point of this post. Without getting on a soapbox about how things have changed… its safe to say that we are seeing more “fracturing” of the internet landscape than ever before. And that trend will only continue. Here are a few facts that point at this trend:
- We used to test on IE on a PC (back in the day). Now we test on IE, Firefox, Safari, and Chrome on both PC and Mac (at bare minimum).
- We never used to test on mobile devices unless we were specifically working on a mobile application. Now we always do some sort of testing on the iPhone browser.
- Video online blossomed via the Flash Player. Today you can watch online video through applications on mobile devices, xboxes, silverlight, and HTML5 just to name a few.
We expect this trend to continue. New browsers are entering the market. IE6 is dying (finally!). And new standards are emerging.
A new playing field
I believe that Apple has forever changed the game. (I do not believe it is a game that will be “won”, however.) Apple lovers & haters aside, the iPhone was the most significant change to the online landscape (beyond just mobile devices and phones) in the last few years. And the exclusion of Flash on the iPhone cannot be ignored as a major turning point for Flash.
First let me say that I LOVE the iPhone. I love the phone itself. And I love developing for it. I feel that same excitement I felt about Flash 10 years ago. Apple has done so many things right and the platform delivers on a new set of promises that Flash is not ready to embrace.
It is not a random occurrence that Apple succeeded where Microsoft failed in the “smartphone” market. Apple has created a closed and controlled platform – and it is because they understand users better than anyone else. We don’t care WHY our phone crashes… we just find it completely unacceptable when it does, and we will blame the phone. Apple has vigorously protected the phone in every way – from their SDK, to their control of distribution, to their (oft maligned) approval process. I am one who believes that they are more RIGHT than they are wrong. And they are winning because of it.
And I hate to say it, but having learned what I know about how the phone works and the rigors of developing for iPhone… I don’t see how Flash can meet the standard. Not without a major shift in the platform.
If I put the Flash Player on my iPhone, I could then write a Flash file in about 10 minutes that would crash the phone – guaranteed. That, to Apple and to me, is unacceptable in this environment.
But Adobe has a conundrum. I believe that they have slowly been developing the Flash platform to a point where it is much more rigorous and standards based. It is much more rigorous to write ActionScript3 than it is to write AS2 – and that is the trend they have been been pushing. But Adobe’s biggest coup is also their biggest problem – every version of the Flash Player is completely 100% backwards compatible. That means that Flash code I wrote in 2001, using simple ActionScript 1, will still run in Flash Player 10. If they ever break that backwards compatibility, the platform would be in major trouble.
But the reality is they may not have a choice. To me, the signs point to the fact that Adobe will be forced to deliver a new standard – more likely closer aligned to AIR than to SWF that will enable some sort of Flash capability on the Apple platform. And its the iPad that clinches it for Apple. IF the iPad is successful, and I believe it will be, Adobe will be forced to bifurcate the platform. They have probably already lost the war in terms of video. All video platforms are already working on HTML5 alternatives and I don’t think Adobe can counter with a Flash Player that works better and has less overhead.
I can see a path where a new Flash Player is introduced for mobile and “intermediate” platforms like the iPad. One that no longer supports legacy Flash – but requires ActionScript 4 (hee hee) and a more rigorous standard of code development. One that has more built-in control for runaway processes and crash-inducing code. (the old “this flash movie is looping uncontrollably” pop-up has got to go.)
So where does this go?
Short Term: I think Adobe must be working on a path forward and an announcement may come soon. But the true short term test will be the success of the iPad. If it really takes off, Adobe’s hands will be tied to providing some sort of Flash Player that passes muster.
Long Term: I am very confident Flash will continue to exist. It just works too well for the simple experiential design element, interactive piece, presentation, etc for it to go away entirely. But all signs point to complication for developers such as myself. JLOOP is taking strides to make sure we can deliver solutions for all platforms that have traction… now and in the future. This will mean we need to be able to develop for the mobile world as well as the traditional browser-based web. The app culture is here to stay. But its not the only game in town. For better or for worse, we have to be ready for anything.
We’re a finalist for the App Star Awards
by jay
DoWeHaveEnough is a finalist! Help us win!
Many of you probably know we’ve been working on a streamlined event utility called DoWeHaveEnough. Its a very simple little application that helps you plan the type of event that can only happen if you have enough participants. Things like… a poker game… a golf foursome… a basketball game. Stuff like that.
We’ll we’ve been hard at work developing a companion iPhone app that integrates with the web application. And we just found out that we’re a FINALIST to win something called the Appsfire App Star Awards! These awards are for showcasing brilliant upcoming apps (not yet released).
The winners are announced next week at the LeWeb conference in Paris. Please visit our page and rate us with a thumbs up to help us!
Here’s the demo video we produced to enter the contest:
And if you would like to be notified by email when the app hits the iTunes App Store, you can sign up today at http://dowehaveenough.com.
Give the app a try and let us know what you think!
A JLOOP Halloween
by jason
Trick-or-treat.
We had a JLOOP party. Pizza, candy, pumpkins, piñata, candy, costumes, dry ice, noodles, candy corn, monsters, candy, and more candy…the kids loved it.
Check out the JLOOP festivities by clicking on one of the thumbnails below:
My favorite moment from last night was when I told Micah (the scarecrow), “Hey Scarecrow, Nice costume…you look scary”
And he responded with “Youre welcome”.
Stay Gold.
CakePHP jQuery Ajax Helper + remoteTimer
by brother mike
We recently made the switch from the default Prototype + Scriptaculous required Ajax Helper CakePHP comes with to the jQuery version found here: http://blog.loadsys.com/2009/05/01/cakephp-jquery-ajax-helper-easy-scriptaculous-replacement/
This solved the conflict issues we ran into when needing Ajax/Prototype but also jQuery.
Just ran into one problem today though, I no longer was able to make Auto Updating Divs with remoteTimer function as that was left out from the new ajax helper.
With a little searching I found a jQuery addon: http://github.com/ncr/at_intervals/blob/master/jquery.at_intervals.js and then made my own remoteTimer function in the helper. Here is the first draft of it working for anyone who might have a similar situation.
return $this->Javascript->codeBlock(”jQuery(’#{$id}’).at_intervals(function() {” . $this->remoteFunction($options) . “; return false;}, { name: ‘”.$name.”‘, delay: “.$frequency.” });”);
}
and an example from my view:
There is some redundancy that can be cleaned out but for now its working and I like it.
Coming in November – MailMan Upgrade!
by courtney
Over the last few months, we’ve been working on a prettier and perkier upgrade to our email marketing system, MailMan. The coming interface will make email marketing easier, more intuitive and a bit, well, shinier. The official roll-out will be later this fall, and we promise to give you more details, but we wanted to give you a heads up first. So, hey, heads up!
Don’t know what Mailman is? Well, why don’t you just say so! We are pretty proud of this easy-to-use yet oh-so-powerful tool. Drop us a line (by emailing or calling us at: 562.491.5667) and we will get you all the details.
Call Fancybox from Flash
by jay
So we searched high and low for a good answer to this one and finally cobbled together a good solution.
Fancybox is a really nice jQuery plugin that gives you some handsome options for the div overlay. We are using it in a new project, but needed to call it from Flash, and there was really no documentation for how to do this. Hopefully our solution will help someone else.
Here’s the really simple javascript function we added onto our page:
<script type="text/javascript" >
function callFancy(my_href) {
var j1 = document.getElementById("hiddenclicker");
j1.href = my_href;
$('#hiddenclicker').trigger('click');
}
</script>
Now somewhere on the page we had to add a “hidden” <a> tag that we could manipulate with javascript like this:
<div id="hidden_clicker" style="display:none;"> <a class="overlay-flash" id="hiddenclicker" href="#" >Hidden Clicker</a> </div>
The tag is wrapped in a div tag that has a display:none set so it doesn’t show in the browser.
Next part is the ActionScript. We embedded the SWF using SWFObject and can call the javascript function just like this:
getURL("javascript:callFancy('/linktopage.html');");
That’s it. Hope it helps someone out there. 
UPDATE 8/18/09: I neglected to point out that the A class assigned to our “hiddenclicker” div is a custom javascript implementation to launch a certain window. Here is the code we added to an included .js file:
$(document).ready(function() {
$("a.overlay-flash").fancybox({
'padding' : 0,
'zoomOpacity' : true,
'zoomSpeedIn' : 500,
'zoomSpeedOut' : 500,
'overlayOpacity' : 0.75,
'frameWidth' : 530,
'frameHeight' : 400,
'hideOnContentClick' : false
});
});
Sorry for the omission…
Kicking IE6 to the curb
by jay
Its time, folks.
IE6 has got to go. We are now two significant versions beyond IE6 and the lengths to which we must go to support IE6 have gotten to be too much. Very encouraged by this news today that YouTube is probably considering dumping IE6 support in an upcoming release. That should be the death knell.
Here at JLOOP we’ve dropped default support for IE6 in new projects and encourage our clients to use an “alert bar” that detects IE6 and shows a message to suggest that the user upgrade to a newer browser. We truly believe this is a reasonable step. With the coming of HTML5 and many new technologies, support for IE6 is going to get even more costly. We want to do our part to kick it while its down.
Please join us!
Lightbox ‘Close’ button not working
by daniel
Okay, so we were building another site that uses Lightbox in a photo gallery – problem was, the ‘Close’ button didn’t appear to work in Firefox or Safari. The ‘Close’ image was in place, but you couldn’t click on it. After some muddling around, we figured out what the problem was.
On this particular site we had set some styles for floated images that would add margins around them to give some space between the image and other content.
.left { float: left; }
img.left {
margin-right: 15px;
margin-bottom: 10px;
}
For some reason, it appears as if those styles are getting applied to the image in the Lightbox photo gallery, causing it to have a bottom margin that overlaps the ‘Close’ link – and only in Firefox and Safari.
So we just added a new line in our lightbox.css file:
#imageContainer img { margin-bottom: 0; }
magentocommerce.com 400 bad request solved
by jay
This is super geeky.
But if I’ve been having this problem this long I have to believe there are others. For the last two months, I’ve been completely unable to browse the magentocommerce.com website in Firefox – major pain, considering I’ve been working on two magento projects. Every time I visited I would get a “400 Bad Request” error.
I tried turning off all my Firefox add-ons – to no avail. Finally figured it out. It was a bad cookie that somehow the site had stored on my machine.
I used the Web Developer Toolbar to clear out all the site cookies for magentocommerce.com and that did the trick. Hope this helps someone else from pulling all their hair out.