Update: Here's the newest "macromedia dreamweaver mx crack"... don't settle for older ones, be up-to-date!
Saturday, May 11, 2002
Are you here looking for "macromedia dreamweaver mx crack"? You might want "macromedia flash mx crack" or "macromedia coldfusion mx crack" too. Here's the super-secret "macromedia mx warez crack", which includes a decoder ring.
Update: Here's the newest "macromedia dreamweaver mx crack"... don't settle for older ones, be up-to-date!
Update: Here's the newest "macromedia dreamweaver mx crack"... don't settle for older ones, be up-to-date!
Reflections on WIRED article: That "Blogging Goes Corporate" article took me by surprise the other day, and it has taken me awhile to digest things.
For me, this page doesn't seem much different than what I've been doing for the last ten years: talking with people online. I started this company-related blog mostly because I type too dang much, and knew that the signal-to-noise on newsgroups and mailing lists was constantly changing and would explode after the new MX announcements. A few years ago I could publish technotes within a few hours, but there's more "process" in the publishing system now, and not all of the interesting breaking news fits a searchable technote format. Most of the real work is being done out in the developer community anyway, it's not as centralized as it was a few years ago. After reading blogs for years I figured this might be a good way to get more efficient in talking with the people I already talk with.
But after the WIRED article, and seeing the impressions from long-time bloggers like Meg, Matt, Jason and others, I realized there's another set of expectations to deal with too, the perspective of bloggers-qua-bloggers. Particularly with that unfortunate "Blogging Goes Corporate" title and phrases like "blogging strategy" (which I never heard of before the article!), what I and my partners are doing runs the risk of affecting what other folks have been doing. (A remote risk, I realize, but you know how I worry.... ;-) I haven't sorted through this yet, but I do feel a sense of responsibility to what these folks have developed... will have to keep thinking on this.
Atop that, I suspect there may be two additional sets of people reading this -- I had not anticipated at all that reporters or other businesses might find this diary, but now it's plausible that other people are here with very different sets of expectations and needs. I don't really care about these audiences at all (crass, I know!), but I may have a responsibility to either set a good example, or maybe make some egregious mistakes so others don't have to make 'em later.... ;-)
I don't want to get distracted from my core goal, of strengthening the developer community for rich internet applications and other publishing/interactive work... these are the people I care most about.
I'll also be looking for ways to satisfy the other audiences, and will be particularly looking for responsibilities I owe the people who pioneered weblogs, but my real goal must continue to be general developer support here.
Anyway, I'm still looking for perspective and guidance on this... catch ya on the lists, thanks in advance.
For me, this page doesn't seem much different than what I've been doing for the last ten years: talking with people online. I started this company-related blog mostly because I type too dang much, and knew that the signal-to-noise on newsgroups and mailing lists was constantly changing and would explode after the new MX announcements. A few years ago I could publish technotes within a few hours, but there's more "process" in the publishing system now, and not all of the interesting breaking news fits a searchable technote format. Most of the real work is being done out in the developer community anyway, it's not as centralized as it was a few years ago. After reading blogs for years I figured this might be a good way to get more efficient in talking with the people I already talk with.
But after the WIRED article, and seeing the impressions from long-time bloggers like Meg, Matt, Jason and others, I realized there's another set of expectations to deal with too, the perspective of bloggers-qua-bloggers. Particularly with that unfortunate "Blogging Goes Corporate" title and phrases like "blogging strategy" (which I never heard of before the article!), what I and my partners are doing runs the risk of affecting what other folks have been doing. (A remote risk, I realize, but you know how I worry.... ;-) I haven't sorted through this yet, but I do feel a sense of responsibility to what these folks have developed... will have to keep thinking on this.
Atop that, I suspect there may be two additional sets of people reading this -- I had not anticipated at all that reporters or other businesses might find this diary, but now it's plausible that other people are here with very different sets of expectations and needs. I don't really care about these audiences at all (crass, I know!), but I may have a responsibility to either set a good example, or maybe make some egregious mistakes so others don't have to make 'em later.... ;-)
I don't want to get distracted from my core goal, of strengthening the developer community for rich internet applications and other publishing/interactive work... these are the people I care most about.
I'll also be looking for ways to satisfy the other audiences, and will be particularly looking for responsibilities I owe the people who pioneered weblogs, but my real goal must continue to be general developer support here.
Anyway, I'm still looking for perspective and guidance on this... catch ya on the lists, thanks in advance.
Installing Netscape Plugins in Mozilla: Useful docs about installing plugins into the release candidates. I haven't proofed this yet myself, but plan on doing so soon... I currently use Netscape 6.x and Opera 5 on Windows and Netscape 4.75 (!) on Mac (hey, it's got a good newsreader! ;-), and check pages in Internet Explorer on both platforms, and will be installing Mozilla RC2 as soon as I get a chance. By the way, if you've got requests for Macromedia's plugin installer or detection routines, please advise the web & installer teams directly in the "General" section of the wishform, thanks!
[via Blogzilla]
[via Blogzilla]
Web services as disruptive technology: Ben Hammersley in The Guardian gives examples of how advances in server communication are likely to be dispersed, with individual developers finding niches for unique, useful services. The angle taken here by ColdFusion (warning: honkin' big PDF) is to make it easier to create and consume web services, and to make it easier to deliver either HTML or SWF interfaces. I firmly believe Ben's point that development will be decentralized, as individual developers create applications for particular audiences and uses.
[via Dave Winer]
[via Dave Winer]
Flash blog UI: This link came up a few weeks ago, but is still under development by Samuel Wan. My current personal take is that blogging is likely one of those tasks better served by HTML, but I appreciate that smart folks out there are exploring all the niches and crannies, trying all the permutations.
(btw, I appreciate the kind words coming up in comments to various blogs out there... I'm sort of shy and usually don't know how to reply, but I like seeing connections deepen over the years, and am glad that people find a way to make a living in this field.)
(btw, I appreciate the kind words coming up in comments to various blogs out there... I'm sort of shy and usually don't know how to reply, but I like seeing connections deepen over the years, and am glad that people find a way to make a living in this field.)
Friday, May 10, 2002
Rob Burgess: "The score is now Adobe one, Macromedia one, customers zero." True, but I'm relieved there's a little more context now.
Financial analysis with Flash front end: This application was done by Root Learning, but I don't know if an example is online... if anyone comes across a link I'd appreciate it, thanks in advance.
A Visual Rather Than Verbal Future in Washington Post describes Ben Shneiderman's work on future interfaces. The article is a little wordy, but he focuses on how the wetware works... the difference in the brain between speaking a set of command instructions or directly and iteratively manipulating an interface element... how we can recognize patterns better when these patterns are in a context... how our visual senses are so highly developed, and therefore how our brain is optimized for visual data.
Quote: "Control, after all, is what Shneiderman thinks is still missing from the computing experience. Computers and the Internet are too darned frustrating, he says, and the only way to put people back in control is through new software designs that are more human-centered, chiefly by leveraging our powerful visual sense. His latest visual tool is the 'timesearcher,' a graphical box that lets people ask questions about massive amounts of data and see the answers visually. Instead of having to type each question using words and numbers ('show me all the stocks that rose in price more than 30 percent between January and April,' for example), the timebox lets you drag around a box on the screen, shrinking or expanding it to explore complex relationships among data over time, with results displayed instantly in an adjacent panel."
There's probably nothing in this article that can help directly with your work today, but it's good brainfood, and may be a useful bookmark for a client someday.
Quote: "Control, after all, is what Shneiderman thinks is still missing from the computing experience. Computers and the Internet are too darned frustrating, he says, and the only way to put people back in control is through new software designs that are more human-centered, chiefly by leveraging our powerful visual sense. His latest visual tool is the 'timesearcher,' a graphical box that lets people ask questions about massive amounts of data and see the answers visually. Instead of having to type each question using words and numbers ('show me all the stocks that rose in price more than 30 percent between January and April,' for example), the timebox lets you drag around a box on the screen, shrinking or expanding it to explore complex relationships among data over time, with results displayed instantly in an adjacent panel."
There's probably nothing in this article that can help directly with your work today, but it's good brainfood, and may be a useful bookmark for a client someday.
Thursday, May 09, 2002
ColdFusion slower? Jochem van Dietan points out in the "ColdFusion: Getting Started" newsgroup a fact-of-life with Java on the server: the first time you use a routine it will be compiled on the server, and will be perceptibly slower than subsequent accesses. This can be a recurring gotcha during development, but will not have an effect on realworld delivery.
Meg Hourihan points to the WIRED article and raises some questions. If I could risk a paraphrase before reply:
Thanks for the comments and concerns, though... it seems pretty clear that after today we'll have a number of additional audiences to satisfy, a number of additional things to think about.
- Isn't on Macromedia site: True. It's an experiment, during this Preview Release. From what we've seen we may implement in-house for both external and internal blogs, but we individually went into various services for experience and speed.
- Doesn't identify as employee: True again, at least in my case. I've been aiming at developers and existing customers, but now that that WIRED story broke (surprise to me!) I may have to handle a different set of expectations, true.
- Is work site, or personal site?: I don't know... the two are blended together pretty closely for me. We'll have to figure out the balance, particularly after the WIRED article changes the audience.
- MM site doesn't point: It's still an experiment. I had been keeping this blog privately for awhile, until I got outed to the blogging community, and I published links in my recent column and have it in my sig. I don't know what we'll be doing in the future, it's still an experiment.
Thanks for the comments and concerns, though... it seems pretty clear that after today we'll have a number of additional audiences to satisfy, a number of additional things to think about.
Recent technotes: You can bookmark these searches for the most recent technotes about Macromedia Flash, Dreamweaver, Fireworks, Director, and so on. This is a good way to check on breaking issues with the Preview Release. (Existing ColdFusion documents aren't yet in this search system, but that's definitely on the list of things to do.)
"Dumb idea": Well, that's what I said, but did those folks at a particularly litigious company listen to me? Nooo-oo. ;-)
"'We haven't issued forecasts for the industry in two years, because the market's going nowhere,' said David Card, an analyst with Jupiter Media Metrix. 'E-books were a dumb idea. I am very negative on this market.'"
I think this may be another specification-versus-implementation issue. The "ebook" readers introduced in the late 90s were big bulky things. That doesn't mean that future implementations could not be comfortable. Foldable paper-thin displays, or glass-mounted projections, or things like that could be adopted by people.
But -- what is reading? I gain information visually in various ways... when I'm hunting something down through Google I have a different visual style than if I'm reading an article, or if I'm responding to an email, or if I'm holding something in my hand. There's not one monolithic thing called "reading text"... there are many different reading styles we use. And that's just for text delivery -- illustrations, animation, videography all convey visual information too. What is the type of reading that people would want to be doing when they happen to have a particular device at hand? I think that's the question that needs to be answered before betting which text-delivery methods will be popular among people.
"'We haven't issued forecasts for the industry in two years, because the market's going nowhere,' said David Card, an analyst with Jupiter Media Metrix. 'E-books were a dumb idea. I am very negative on this market.'"
I think this may be another specification-versus-implementation issue. The "ebook" readers introduced in the late 90s were big bulky things. That doesn't mean that future implementations could not be comfortable. Foldable paper-thin displays, or glass-mounted projections, or things like that could be adopted by people.
But -- what is reading? I gain information visually in various ways... when I'm hunting something down through Google I have a different visual style than if I'm reading an article, or if I'm responding to an email, or if I'm holding something in my hand. There's not one monolithic thing called "reading text"... there are many different reading styles we use. And that's just for text delivery -- illustrations, animation, videography all convey visual information too. What is the type of reading that people would want to be doing when they happen to have a particular device at hand? I think that's the question that needs to be answered before betting which text-delivery methods will be popular among people.
"Why DHTML Will Win" by Steve Champeon is worth a read. I'm not sure of the zero-sum premise (what's "win"?), but I absolutely agree that it's worth re-examining DHTML now.
Key concept: Definining a file format is one task. Achieving distributed realworld capability is a separate and much more difficult task.
When DHTML was introduced, most realworld browsers had good convergence around the HTML 2.0 spec... you could confidently design with tables and FONT tags and what-all. When the 5.0 browsers came out there was more practical convergence around the HTML 3.2 spec. Now that the browsers have gone through another generation, we see that what people have on their machines out there and pretty realistically support the HTML 4.0 spec.
The Macromedia Flash Player has a faster feature-to-deployment cycle -- a faster adoption pattern, a faster update rate -- because it's a smaller download than a browser, and imposes less environmental changes on each site visitor than changing their browser would impose. Flash usually reaches majority consumer viewership within a half-year of introduction, but browsers may be closer to an 18-24 month cycle. It's still the same pattern, just a different rate.
(I think Steve missed some of the practical advantages of SWF for internet applications... there's a single streaming connection rather than multiple HTTP negotiations, scripting is far more compact than text JavaScript, there is no need to refresh a page after a data request, and so on... but these will be proven by actual realworld implementations rather than by discussion.)
Macromedia MX uses both HTML and SWF for client-side delivery. I think both formats will "win", myself, but Steve's always worth listening to, give 'im a read.
[via ActionScript.com]
Key concept: Definining a file format is one task. Achieving distributed realworld capability is a separate and much more difficult task.
When DHTML was introduced, most realworld browsers had good convergence around the HTML 2.0 spec... you could confidently design with tables and FONT tags and what-all. When the 5.0 browsers came out there was more practical convergence around the HTML 3.2 spec. Now that the browsers have gone through another generation, we see that what people have on their machines out there and pretty realistically support the HTML 4.0 spec.
The Macromedia Flash Player has a faster feature-to-deployment cycle -- a faster adoption pattern, a faster update rate -- because it's a smaller download than a browser, and imposes less environmental changes on each site visitor than changing their browser would impose. Flash usually reaches majority consumer viewership within a half-year of introduction, but browsers may be closer to an 18-24 month cycle. It's still the same pattern, just a different rate.
(I think Steve missed some of the practical advantages of SWF for internet applications... there's a single streaming connection rather than multiple HTTP negotiations, scripting is far more compact than text JavaScript, there is no need to refresh a page after a data request, and so on... but these will be proven by actual realworld implementations rather than by discussion.)
Macromedia MX uses both HTML and SWF for client-side delivery. I think both formats will "win", myself, but Steve's always worth listening to, give 'im a read.
[via ActionScript.com]
Wednesday, May 08, 2002
David Burrows: "The feeling I had in the beginning is coming back. The people who understood the net are still here - they can't go anywhere else, they've seen the promised land." Pints are on me. ;-)
Mozilla LiveConnect is still a dicey thing... it looks like it's getting frozen now, but it would still be far away from realworld use. (Shockwave and Flash introduced LiveConnect support back when the browsers could do things plugins couldn't.)
btw, old article but a goodie... Steve Champeon's history of JavaScript at O'Reilly.
btw, old article but a goodie... Steve Champeon's history of JavaScript at O'Reilly.
FoxSports navbar is still a cool piece of work... granted, the overall page is busier than my own level of testosterone can handle, but check out how that "Site Nav" option at the top can segment so much information, so effectively. I have no idea what all of that would cost in GIF, markup, and text script.
Jeffrey Zeldman refines his feeling about the balance between SWF and HTML. I'd replace "animation" there with "interactivity" myself, but the balance points between technologies do change with time.
New Scientist article on "swarming jazz software" is proof positive that text is sometimes not as accessible as SWF.... ;-)
[via Daypop Top 40]
[via Daypop Top 40]
Matt Berger at InfoWorld discusses economics of the Java server market. Macromedia has JRun in this space, which does well in situations which call for something more economical than a large enterprise system, but JRun is also a component embedded within other applications such as Macromedia Generator and standalone ColdFusion MX.
ColdFusion avoids this server commoditzation by providing efficient development services atop various appserver substrates... by this time next year we may see ColdFusion regarded more as "that smart way to create and consume web services" rather than as "that smart way to make database-driven pages". (Or maybe not, I'm not always spot-on predicting the future.... ;-)
Anyway, it's a useful article for an inside look at the server market... shows again how it's not just the software, but people who use the software, who really push things forward.
ColdFusion avoids this server commoditzation by providing efficient development services atop various appserver substrates... by this time next year we may see ColdFusion regarded more as "that smart way to create and consume web services" rather than as "that smart way to make database-driven pages". (Or maybe not, I'm not always spot-on predicting the future.... ;-)
Anyway, it's a useful article for an inside look at the server market... shows again how it's not just the software, but people who use the software, who really push things forward.
Next up: Colonel Sanders rates the various fast food restaurants...? ;-)
Flash Player buffer overflow: Sorry I'm so late on this... I've been waiting word from engineering about what exploit actually is, and so far I don't see a fact-based explanation on the Macromedia Security Center. It sure sounds like the read buffer overflow which made headlines 15 months ago, only this time it's a malformed address in the OBJECT tag rather than a malformed SWF file which reads until it keels over.
One of the things that ticks me off is how the initial press release from the security software company, and then the subsequent articles, and then the mentions on the various lists, use worst-case lines like "exploit can cause foreign code to execute". That might be true if it were an executable buffer which overflowed, but from what I see both of these are reading buffers. Even if you could pass bad code to the Flash Player this way, it still can't break out of its sandbox. If fed malformed stuff, the browser can crash, that's the worst actual exploit I've seen.
But we messed up, we should have had a technical explanation up on the site immediately. I let this ball drop, personally, because I'm still caught up in the rush of the Macromedia MX Preview Releases... I should have pushed to make sure we put better information up on Friday. If you lose time with this because one of your clients is concerned, please give me flak about it on the lists, and I'll be guilt-ridden enough to give my partners a hard time in return, thanks.... :(
One of the things that ticks me off is how the initial press release from the security software company, and then the subsequent articles, and then the mentions on the various lists, use worst-case lines like "exploit can cause foreign code to execute". That might be true if it were an executable buffer which overflowed, but from what I see both of these are reading buffers. Even if you could pass bad code to the Flash Player this way, it still can't break out of its sandbox. If fed malformed stuff, the browser can crash, that's the worst actual exploit I've seen.
But we messed up, we should have had a technical explanation up on the site immediately. I let this ball drop, personally, because I'm still caught up in the rush of the Macromedia MX Preview Releases... I should have pushed to make sure we put better information up on Friday. If you lose time with this because one of your clients is concerned, please give me flak about it on the lists, and I'll be guilt-ridden enough to give my partners a hard time in return, thanks.... :(
Samuel Wan is interested in telerobotics -- device control. I'm fascinated myself, was a member of Home Brew Robotics Club long ago, and got turned onto X10 home automation, Beehive Technologies back during Director's XCMDGlue days. These days companies like emWare are making embedded controllers smaller.
I think the economics would be with a universal controller... your normal PDA should be able to pull from sensors and push to controllers... you shouldn't need a different device for each task, you should be able to just retrieve a different interface for your usual device. Sometimes there would be direct line-of-sight communication, but I suspect the general path would be to go through a server. Things get interesting when your portable interface can use distant video feeds.
I think the economics would be with a universal controller... your normal PDA should be able to pull from sensors and push to controllers... you shouldn't need a different device for each task, you should be able to just retrieve a different interface for your usual device. Sometimes there would be direct line-of-sight communication, but I suspect the general path would be to go through a server. Things get interesting when your portable interface can use distant video feeds.
Tuesday, May 07, 2002
Takeout food: I usually ignore flyers hooked on doorknobs in San Francisco, but yesterday I saw a pizza delivery had a website and I checked it out. Waiter.com is actually a franchise site for multiple restaurants... take a glance at this 200K listing of San Francisco restaurants.
Try clicking a new-window link, like "What's New", and take a look at the source of these two files. Towards the top of the page you see that every page has the full list of restaurants included in the HTML file. Further down on the SF listing you'll see that each restaurant requires about a kilobyte of markup to render.
Using SWF on the client would be sooo much more efficient. You wouldn't lose state between user interactions -- that listbox of restaurant names could be downloaded _once_ and remain right in the interface. The details for each SF restaurant could be sent as data rather than as styled text... why should the server have to write out all those redundant formatting tags? Separate the data from the presentation, let the clientside SWF file apply formatting rules to some relatively-compact XML data instead. If the site's visitor wants to examine a particular restaurant in detail, then let them _keep_ the data they've already downloaded, don't ditch it all!
Granted, the site is still useful, and I'll use them again myself, but this is a great illustration of what Jeremy and Kevin have been saying about "there are situations where HTML breaks down"... it's this type of _web_task_ which can be much more efficient and pleasant when using a rich internet application rather than overloading a hypertext markup language!
Try clicking a new-window link, like "What's New", and take a look at the source of these two files. Towards the top of the page you see that every page has the full list of restaurants included in the HTML file. Further down on the SF listing you'll see that each restaurant requires about a kilobyte of markup to render.
Using SWF on the client would be sooo much more efficient. You wouldn't lose state between user interactions -- that listbox of restaurant names could be downloaded _once_ and remain right in the interface. The details for each SF restaurant could be sent as data rather than as styled text... why should the server have to write out all those redundant formatting tags? Separate the data from the presentation, let the clientside SWF file apply formatting rules to some relatively-compact XML data instead. If the site's visitor wants to examine a particular restaurant in detail, then let them _keep_ the data they've already downloaded, don't ditch it all!
Granted, the site is still useful, and I'll use them again myself, but this is a great illustration of what Jeremy and Kevin have been saying about "there are situations where HTML breaks down"... it's this type of _web_task_ which can be much more efficient and pleasant when using a rich internet application rather than overloading a hypertext markup language!
Monday, May 06, 2002
Got a tip? I've been asked to remind folks that there's a contest for tips about using the various applications. I know it's difficult to visualize something which isn't yet visible, but they'll give someone a new computer for doing it, might as well be you...? ;-)
J2EE reaction to Flash MX client: This reader-response column to an article about Macromedia MX appearing on a server-side Java board was already linked by Mike Chambers, but I think it's interesting enough to double-link... the goal is to get predictable interactivity and advanced functionality regardless of playback environment, and it's interesting to see how people who have already invested in learning Java see the advantages in such a predictable client-side engine.
There's some background info there from Sean Neville on the Macromedia development team, and it's also fascinating to see the gradual evolution of ideas about tying clients and servers together. Worth a scan.
There's some background info there from Sean Neville on the Macromedia development team, and it's also fascinating to see the gradual evolution of ideas about tying clients and servers together. Worth a scan.
Ban Kaboom SWF? Netcomic site Newgrounds has been asked by a member of US Congress to remove a SWF game dealing with bombers. (They're not "suicide bombers" by the way... if anything they're "hired homicide bombers".)
[via GeekNews]
[via GeekNews]
Daily crack reminder: If you arrived here looking for "dreamweaver mx crack" or "macromedia flash warez" or such, then use your head for a moment.. think!
The Macromedia Dreamweaver MX Preview Release is free. By the time it expires there will be a release version available. There is zero practical reason to download and execute some code from an admitted criminal site to defeat its timeout.
On the other hand, there are many reasons for those who crash airplanes into buildings to want to insert code on your computer for massive coordinated denial of service attacks. You're welcome to be an idiot if it affects only yourself, but because your stupidity in running criminal software can affect others, please just stop, think for a minute, and be more of the human that you can be.
The Macromedia Dreamweaver MX Preview Release is free. By the time it expires there will be a release version available. There is zero practical reason to download and execute some code from an admitted criminal site to defeat its timeout.
On the other hand, there are many reasons for those who crash airplanes into buildings to want to insert code on your computer for massive coordinated denial of service attacks. You're welcome to be an idiot if it affects only yourself, but because your stupidity in running criminal software can affect others, please just stop, think for a minute, and be more of the human that you can be.
The Register has an interview with Jeremy Allaire on Macromedia MX, exposing a slightly different side of the initiative. Quotes: "MX, said Allaire, 'is not a version upgrade, but a change in how people do things'... There are problems on the server side too, Allaire said. Each application tends to become a 'silo' isolated from all the others. Even when given a web front end, it is still locked into a specific set of scripts and HTML pages. This is too rigid - and thus too expensive when, as often happens, it needs to be changed or extended... Macromedia has always maintained a scrupulous (and pragmatic) balance between the worlds of Microsoft Windows and non-Microsoft technology such as Java."
Waldo Smeets extends the context-sensitive scripting reference from Macromedia Flash MX into Dreamweaver, useful if you prefer a single coding environment. Waldo also has a good summary of what people are thinking and doing in the UltraDev community... also doing some work with Flash Remoting. Great stuff, check it out.
Benny Evangelista on Macromedia history: Yes, the slide between floors on Townsend St is gone. We had originally wanted a firepole, but the SF Building Inspectors advised it was too dangerous, and wouldn't let us use a firepole. Fortunately they haven't yet found out about the midnight bungee-jumping....
[via Robert Occhialini]
[via Robert Occhialini]
Searching SWF: Some oddities in this article on search engine optimization for Macromedia Flash MX... some search engines do indeed index text & links with SWF (see Atomz, eg)... if you should "never" use a SWF navigational structure then you wouldn't be able to find anything on the Macromedia site... "do not have all your content in SWF" does not distinguish between text data and other content (their's emotive content as well as verbal content!)... "don't make a 5-minute movie" is true, but is a special case of "don't make a 5-minute page"... it's great that people advise each other on how to best use these new abilities, but sometimes some advice on the advice might help too.... ;-)
[via CHris MacGregor]
btw, SWF files can place highly on Google... part of what they index is what's in your file, and part of it is what links to your file. Try a search on "osama filetype:swf".
[via CHris MacGregor]
btw, SWF files can place highly on Google... part of what they index is what's in your file, and part of it is what links to your file. Try a search on "osama filetype:swf".
Future Flash Components: Julie Thompson of Macromedia is seeking feedback on which types of components would be most useful for you in Macromedia Flash MX. She's apparently particularly seeking comment on how well three existing components sets match your own vision of what the app should be (that's the two current Flash UI Component sets and the Flash Charting set).
I imagine she'd want to hear from three distinct sets of people: Flash designers who use components; developers who write components; and people who haven't used Flash much before who are using components to help their ColdFusion or other development.
The Macromedia Exchange is being revamped, and the new version will be atop a ColdFusion base, but she's also seeking confirming word on how you'd like the Exchange to evolve too. Thanks for any advice!
[via Mike Chambers]
I imagine she'd want to hear from three distinct sets of people: Flash designers who use components; developers who write components; and people who haven't used Flash much before who are using components to help their ColdFusion or other development.
The Macromedia Exchange is being revamped, and the new version will be atop a ColdFusion base, but she's also seeking confirming word on how you'd like the Exchange to evolve too. Thanks for any advice!
[via Mike Chambers]