=============================================================
EDIT:
1. The project started here: http://think-a-doo.net/node/217
2. Then we did a complete re-write to make it more modular
3. This is where we are now: http://think-a-doo.net/node/225
Chat Update in Catalog -- http://lab.think-a-doo.net/11_ChatUpdate/Catalogue.html get the AIR version here -- http://lab.think-a-doo.net/11_ChatUpdate/Catalogue.air (145Kb)
The performance is significantly better and the code more stable.
We are considering using Soma as a Display Framework -- http://think-a-doo.net/node/221
Will keep you updated.
=============================================================
This was a long hard learning curve.
http://lab.think-a-doo.net/CMS/PENS -- back end
http://lab.think-a-doo.net/RIACatalog/Main.html -- front end
We wrote the whole front-end in pure AS3 and connect to Drupal 6.15 through the new AMFPHP 1.9 server.
Looking at the performance, it was well worth the effort.
Drupal can change everything you see on the screen, the Backgrounds, the Product info and images, the Logo associated with the product. Taxonomy is used to create the category menus too.
The whole site is maintained by Drupal.
The application is designed to run in browser full screen mode. (see trouble with fixed size discussion below)
EDIT: I am currently preparing the AIR application pending our investigation into 960.gs and BluePrint. If 960.gs or BluePrint can offer the same layout control we would like to keep Drupal for the browser, AS3 version (which made the current front end) for AIR and Drupal for the cell Phone (although that is not an original design requirement)
EDIT: Progress: I have made a quick TECH demo of a chromeless, semi-transparent AIR version of our catalog project. I am reluctant to post it here as it its really just an exploration of the possibilities with AIR, not a designed outcome. If you want to see the progress and accept that it is simply a TECH test, feel free to email me and I will send you the AIR app as an attachment (500Kb). If you are patient and would rather see the final result of our exploration, I will post it here when it is ready for release.
Comments
What made you decide to do
What made you decide to do the whole thing in Flash? I really cannot see the need for it in your case. All that does is make you harder to index by search engine bots and by extension harder to find by people using those search engines. People who depend on screen readers will not be able to use your site, nor will anyone who does not have or want to use flash (forget about any iphone users visiting your site). People with slow connections may also stay away since flash is fairly heavy.
You say your site is designed for full screen use, but what about people with small screens? You just cannot make assumptions about the size of the window visitors to your site have.
In short, many disadvantages, with nothing to show for it, that i can see.
sorry, it looks like it could be a nice site, but not in Flash.
EDIT: I don't see a scroll bar either BtW, is that intended?
-------------------------------------------------------------------------
ExtendOpera.org, extend your Opera.
What influenced our decisions (Not a Defence)
Hi Dirk.
Thank you so much for your comments. I must say, doing this project so far, I have asked myself many of the same questions.
I have teamed up with Jan Erasmus http://cybergraphics.bz/ on this project. I have known Jan for years, and in order to offer him a pixel perfect layout canvas in which he can design whatever he likes I still think Flash is a good option. Add to that the fact that Jan already designs in Flash, and the idea of trying to style a PHP generated site just did not seem feasible. I lack the Drupal theme design skills to make it look like Jan's design. So the choice of Flash was initially almost made for us as a catalog design team.
Having said that, I started doing performance tests with Charles http://www.charlesproxy.com/ and was very surprised at what I learned. We managed to keep the SWF file below 150K and it currently takes 6.5 Seconds to load without any pre-loading strategy. My Google account takes 45 seconds to render all the content and then spends some time doing Ajax for docs and chat. I'm not sure how much longer. What surprised me was the benefit Flash gets from being in the browser. All the images we load from Drupal are HTTP and not AMF, so this allows the images to cache in the browser cache functionality. The SWF also caches in the same way. With the display framework in place, all we end up calling is the Views service to give us the latest list of products and loading the images from browser cache.
The traffic profile of the site is actually looking exactly as promised by the RIA folks. Slightly heavy on the first hit and then extremely fast after that. I like that about the Flash front end.
The screen size is a problem for Jan and I. We have no idea how to solve it. Jan is clear that the catalog must not be allowed to do the layout dynamically. He is using the Golden Ratio in his design and an auto layout approach will break that design intention. Remember I am (as a programmer) bound to make the design intentions of my design partner come to life.
We decided (for better or worse) to set a limitation from the start: "fixed size". I have suppressed the scroll capability intentionally to clean up the browser window. What I am thinking of is to imitate scrolling by moving the whole site up to just reveal the Category buttons and below, as soon as you move you mouse into the product list area. Then to reverse the move as soon as your mouse enters the Category buttons area. I intend do it for screen sizes smaller than 1280x800. That may work.
An unintended benefit is that we can now have a central data store service and the clients can deploy their Flash RIA on their own web host or anywhere. That solves a number of political issues for us. We anticipate less hassles with deployment by separating the display framework technology from the application and data store.
We will also have an AIR version of the catalog, but that requires that we manage image cache in our application, and that means a reasonable amount of additional work which we have committed to.
We are not currently planning to make a Flash or AIR mobile app. In fact I hope to set up the current back end (Drupal) to deal with the mobile angle (with an appropriate mobile theme of course.
In summary:
I am not defending our choices, I have gone to bed at 2-4 AM for the past 6 weeks having the same doubts.
1. I have learned something about the performance of Flash as RIA front end to a PHP development framework, and I like what I see.
2. Auto layout is everywhere and I agree with Jan, that in the case of Catalogs specifically, we will differentiate our product better, by controlling the design layout and ratios.
3. Screen size becomes an issue as soon as we committed to (2). The only solution I can think of is to make multiple versions at different sizes. Any other suggestions are welcome.
4. Remember we are entering the Catalog genre. We are not just making a web site. Jan may in most cases actually design the printed version.
Actually any suggestions, whatsoever, are welcome.
Does that at least make our strange approach make more sense?
You've clearly thought this
You've clearly thought this through :-) And for a flash site it is impressively responsive.
But, while you may have good reasons for using Flash, i am afraid that you are sacrificing function on the altar of form. Making several versions of your site for different screen sizes, apart from being extra work for you and the designer, does not solve your problem IMO. It's perfectly possible to know what size screen a visitor is using but AFAIK it is not possible to discover window size before the page is loaded. Many people, especially those with big screens, do not maximise their browser window, using the extra space for other purposes. Of course, you could add a notice telling them to maximise their window but i don't think people would like that much. That said, i know little of developing websites with flash and have no idea if or how making a more dynamic design would work.*
Solving the lack of scroll bar the way you described may work but it may also confuse people, used to scroll bars as they are. It does nothing at all about horizontal scrolling, admittedly, 800:600 displays are very rare these days so that may not be a huge issue. If you want to make things neater you could always try styling the scroll bar to make it look more integrated.
While you may be designing a catalogue, it is still also a website and i think people are likely to approach it as such. Certainly the only way they will ever see it is with a web-browsers. The rules are not the same as for printed material. With printed material you control everything, with a website you have little control over what happens on the reader's side of things. You may differentiate yourself by doing what you are doing but i am not sure it would be in a positive way.
*assuming you could convince the awesomely named Jan Erasmus to relent.
NB: I must admit that i am somewhat allergic to the use of flash for making navigation or entire sites, so my posts here are probably biassed. It could be that i am overstating the problems here.
-------------------------------------------------------------------------
ExtendOpera.org, extend your Opera.
Convincing a my design partner
*assuming you could convince the awesomely named Jan Erasmus to relent.
Our collaboration is founded on the principle that good form (in our view) will triumph over function. I am absolutely committed to support Jan's pre-visualization and design intent. I am an engineer by trade and have chosen to work with aesthetes to achieve the form they believe will accomplish the objective.
I am well aware of the trade offs involved with balancing the demands both form and function make. But finally at 45, I have decided to do the best I possibly can and not ask the designer to compromise, in as much as that is possible.
As you say: "sacrificing function on the altar of form".
I am trying, the best I know how.
_
I know it can be difficult trying to fight a designer's comfort zone-- but there's a reason you don't see many sites like this built entirely in flash. I see nothing in that site that couldn't be done with a standard theme-- as Dirk said, it's a shame to sacrifice function/usability for form.
All I can say is, as a user web shopping: 1) I would not bother to wait for the first page load and 2) i would never bother with the site a second time. Sorry, :-(
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Where to find help making Drupal look the same?
I am so grateful for both your inputs so far.
Posting here is really helping me to consider the possibilities of doing it with a theme in Drupal.
So, if your advice is to do the catalog in Drupal only, and your experience is that what we have done in Flash can be exactly replicated, where do we need to turn for help? Who can help us?
Our project is self funded and has no client yet, although we hope to offer it to local catalog publishers and photographers who shoot for catalogs.
All we could do is trade equity in "future earnings" for a style that gets the job done as the designer envisaged.
Any ideas?
Anyone interested?
We would really appreciate a collaboration opportunity with someone who understands Drupal theming and advanced configuration.
My email is andre.n.venter@gmail.com
_
I would start with having the designer redo the design in photoshop or fireworks based on a css grid framework (and yes, you can use the golden ratio with a grid). I like 960.gs but there are others. If they're not already familiar with such design, there's tons of articles on the web and some good templates at http://960.gs. Then, it should be fairly simple to convert that to a drupal theme using http://drupal.org/project/ninesixty or http://drupal.org/project/fusion as a basis.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Great advice!
I looked at 960.gs this morning.
What a lovely solution! I was completely unaware of it. What really surprised me is the comprehensive toolkit supplied with it. Jan gave me his initial design in InDesign and 960.gs seems to support the work flow from InDesign to Drupal.
Thank you so much for your most valuable advice and insight. I will do a design check with Jan and spend as much time as needed to come to grips with the production process.
If it works for his design, it leaves us with amazing options. We could get the best of all worlds. Drupal for the browser, AIR for the desktop and Drupal for the phone. I like that!
We will have a tech review meeting a.s.a.p and report back on the way forward. I will also try and find someone in the Drupal community with experience in 960.gs to jump start the process.
Thank you so much for your valuable input.
_
Excellent! Glad you liked it. Grid design/theming takes a little getting used to, but once you do it's really sooooo simple you'll wonder how you lived without it all this time. And I'm finding the fusion drupal theme a wonderful base theme. Good luck-- and post back if/when you finish your theme!
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Thank you so much
I've been working on the AIR version today and will post a link on this article as soon as its presentable.
I've read a lot about 960 and BluePrint today, check out the modules and watched the Fusion demo video. Your advice was invaluable. I just hope the rabbit hole does not go to deep. I also sent mails to two local experts to help us fast track this project in Drupal, but no response so far.
I will keep this article current on our progress.
Thanks again.
AIR progress TECH test
Progress: I have made a quick TECH demo of a chromeless, semi-transparent AIR version of our catalog project. I am reluctant to post it here as it its really just an exploration of the possibilities with AIR, not a designed outcome. If you want to see the progress and accept that it is simply a TECH test, feel free to email me and I will send you the AIR app as an attachment (500Kb). If you are patient and would rather see the final result of our exploration, I will post it here when it is ready for release.
andre.n.venter@gmail.com
All round progress with AIR and Flash components
See the EDIT to the original post for an update
Chat feature added
Integrated chat feature in catalog -- http://lab.think-a-doo.net/10_Integrated/Catalogue.html get the AIR version here -- http://lab.think-a-doo.net/10_Integrated/Catalogue.air (145Kb)
Final Updates to initial Catalog
Chat Update in catalog -- http://lab.think-a-doo.net/11_ChatUpdate/Catalogue.html get the AIR version here -- http://lab.think-a-doo.net/11_ChatUpdate/Catalogue.air (145Kb)
Our next steps are now to add user login, tracking and a shopping cart -- all writing to Drupal from the Web or AIR apps