I don't agree with your UI-design-first approach though. Content should always come first. No content, no UI. At the very least, both should be developed hand in hand.
Claus, Well of course we agree on most if this. And of course your general thrust that a spiderable HTML underpinning is necessary for search engines is right. But on the UI issue perhaps a slight divergence. Perhaps you can do data and UI hand in hand, but my view is that you dont know what your product should really be until you do some form of UI that you can test against real users who can tell you whether you are on the right track. This typically means building some form of UI, perhaps a wireframe though this will give you less good feedback, perhaps not even tied to a server but with mocked up data, for them to experience. If you go right to a data model, then you dont know if the content that you are trying to present is what the user really needs or wants. So I am always focused on making sure that what I am doing is what the user wants first. Once you know you are on the right track, then you can build a data model to present the user what they need. Of course this does not mean that great code cannot be written lots of other ways! Regards, Hank In any case, for an application/website to be truly SEO'ed, you need a
HTML site underneath that search engines can spider. This is all about data and nothing else, and it needs a 1:1 relation to the data that the human user is going to get when she clicks on a link presented by search engines (wrapped in a Flex UI or whatever). Cheers, Claus. > You are of course right to suggest building an XHTML version first, as a > strategy, but there are two problems with this. > > 1. One of the issues is that good product design usual requires that you > develop the interface first. The interface drives the content and data > needed. What you are suggesting may help acheive the best underpinnings, > but it is very hard to design a good product if you start with the data. > The best way to design is really to start with the UI, which flex is > very good at. So you end up with Flex code first and you tweak it with > real users etc. So you probably use some kind or remoting model. Now you > are left trying to figure out a good way to make your remoting based > stuff searchable. > > 2. Even if you decide to do it the way you describe, which is to start > out with an XHTML framework, this model really does not fit the remoting > model very well because you cant build a pure XHTML site based around > remoting. So what you are really suggesting is that you cant use > remoting, which is a cornerstone of the Flex development model, and > develop a searchable product. But throwing out the whole concept of > remoting is really not very appealing from a development model. > > Now, I am sure that it is possible to build a framework that would help > to resolve these issues (and it would be great if adobe would develop > such a thing), but certainly just saying use XHTML first would be a very > hard task for most people, without such a framework, to do in a clean > Flex/remoting friendly way. > > Regards, > Hank -- claus wahlers côdeazur brasil http://codeazur.com.br/ http://wahlers.com.br/claus/blog/ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
