pagoda

feminine

hale

ripen

Greetings, Yes, Bruce is correct, most phones use Java (J2ME, as I mentioned, to be more precise) and can indeed use the Opera browser (a very lightweight browser - no JavaScript, no CSS, no frills at all in fact). However, the PDA version of the Opera browser does in fact allow JavaScript (though it is sometimes broken - not due to Opera's implementation but due to web designer's very weak and incorrect JavaScript - mostly issues with not using assert() and such things) and also CSS. For a while there was a lot of talk about PDA/SmartPhone native Joomla code - but I'm not sure if this ever materialized. As far as the days of WAP being numbered - I wish. I wish it would just go away completely, in fact. Unfortunately, while Bruce is correct in that WAP will go away, it will go out with a wimper and not a bang. Why? Because the telcos wish to hold on to proprietary things like OSes as long as possible - OSes that just allow J2ME apps so the OS itself appears as a blackbox - thus we end up writing WAP since it's hard to write good J2ME, have it used across multiple telcos and accepted as a de facto standard - something akin to CSS and C-HTML, for example. This is why Open Source is (in my opinion) the way to go and leads to progress, while proprietary software leads to headaches. That said, almost every phone can be hacked to varying degrees (but this sometimes ruins a phone - so beware). I also strongly agree with the comment that you get a PDA/Cell Phone emulator - I forgot to even mention those. There are MANY that are free (I've got probably a dozen on my computer) - they truly are great for seeing what a website will look like on a specific device. For example, most Sprint phones can be emulated using the Sprint Wireless Toolkit (just pretend you are a developer and sign up for the SDK - you'll get it and then can use the tools). There is also one that is great called WAP Proof which shows how WML will be rendered on a certain device - free tool, great to use. Finally - get "Pocket Controller Professional" - it costs money and is not freeware. However, what it does is allow you to plug in your phone or PDA into your computer (as if to sync it) and then to see your PDAs screen on the computer and perform all PDA functions in a window on your computer with graphics, etc. all being exactly as on your PDA. Thus, you needn't type on your PDA, write with the stylus, etc. - much, much, faster for development. Take a look at my first photo entry for the contest TCH had at the end of the year - Win An Ipod, Laptop, Or Server....., Post #81 - this shows Pocket Controller Professional in action with the TCH website loaded on my Axim X51v. Glad my previous post didn't quite bore you to tears Good luck! Patrick

mell

green

spire

Greetings Webgyrl, (This e-mail was started yesterday - I've been thinking about it all day! But I never got around to finishing it - so here is my late entry into this discussion...) Warning: long answer with no time to proofread prior to posting... Let me know if something is totally confusing/wrong/etc... There are two main schools of thought (that I am aware of) on this topic, here is my take on both of them, and why you should (or might want to) care about them or why you might not want to care... To the question "how can I think about serving up content to PDAs?" I would posit the following nice vague answers: Tailor the web site to mobile browsers (The Mobile Device-Centric Approach) Use standard XHTML but keep the design and content light (The "Black Box" Approach) Yeah, that's probably an obvious breakdown of the issue and is more or less what you said in your query. But there is really more than that implicitly embedded in your question, and thus the answer is more subtle and contains more twists than what might be implied from the above. The following is how I view the problem when I am working on a site that is either purely for mobile content or else is dual (or triple) use: The Mobile Device-Centric Approach What Constitutes a "Mobile Device" Anyway? Confusion over what type of mobile device one is designing a website for has the potential to waste money, time and effort. Of particular interest, and the reason I said that some website are dual or triple (or better) use is that for better or worse, one must consider cell phone devices in a discussion such as this. As Bruce mentions (albeit in a somewhat vague-ish fashion ), PDA devices do now come with decent web browsers. The only problem (as I see it, and with all due respect) is that I believe Bruce is using the PDA definition that precludes devices that communicate over a phone network and more and more these need to be included in design decisions. In some respects, our lives were a lot easier (at least for those of us who design websites for just these types of platforms) when there was more of a split between cell phones and PDAs. In a nutshell, here is the current state of affairs (greatly reduced and watered down - but enough to illustrate the problems) - it's actually best to start with a cursory glance at the operating systems (IMHO) to jump into the problem: Mobile Device Operating Systems PDA Operating Systems: PDAs range these days and in the last couple years from lightweight computing platforms to devices that are more or less miniature computers (my Dell Axim X51v is more powerful than the Intel DX4 80486 that I used with the much-hyped Windows 95 in 1996 as an example - and their are many "pocket rockets" with even faster processors out there). Why does this matter? This is the enabling technology that has allowed for decent operating systems to evolve on - probably the three most popular (in a very general sense) are: A) Descendants of Windows CE such as Pocket PC, Windows Mobile, etc. Palm OS and variants and C) we are increasingly seeing embedded Linux on PDA (and other) devices. Each of these stripped down operating systems did not use to leave much room for a good browser, but as Bruce correctly points out, increasingly does with the newer devices. Cell Phones: Here is where things get sort of interesting. Your typical cell phone can not run one of the operating systems mentioned above. Why? Because they lack the processing power and increased processing power requires faster processors which requires larger batteries and longer charge times - consumers generally do not like big bulky devices for cell phones - this is also at the heart of why it has been so hard for a company to come up with a good hybrid device (mentioned next) to put on the market. So, what kinds of operating systems do cell phones have? Newer cell phones from the past few years (really any cell phone that actually "does something" or has cool features like a camera, can play MP3s, games, etc...) generally have proprietary operating systems (sometimes embedded Linux disguised and hidden from view) that the consumer really knows very little about. So how then, does anyone manage to create programs, like those cool games, your web browser and other applications for a cell phone? Many (maybe most?) of these cell phones support J2ME, the Java Platform, Micro Edition. It is upon this then that applications are usually built - J2ME is a specific subset of the Java platform. Mixed Devices: If cell phones were "sort of interesting", mixed devices are where the action is at! More and more we are seeing mixed devices - devices that act as a PDA and a cell phone (and don't suck). The enabling technology behind these is faster processors with very low power consumption and thus a smaller form factor, but not so small one cannot either write on the touch screen (if present) or type on the miniature keyboard (if present). These devices show a lot hope since unlike cell phones, which usually have proprietary operating systems, we are back in a realm where a Windows, Palm OS or Embedded Linux OS will work. Suddenly the tables are turned and the (usually proprietary) software to connect to the cell phone network is written on top of one of these OSes instead of for standard cell phones where the proprietary OS itself is on the bottom layer and is mostly concerned with connecting to and using the cell phone company's network. Why does all of this matter anyway? This little bit of background ultimately helps us understand why the browsers we must target for mobile devices end up having the features, lack of features and quirks that they do. We can further understand how to pick our target audience and limit the scope of websites such as the one you are working on (if it needs to be limited) or else to at least know what you are getting in to if the scope is not very limited (i.e. if all three types of devices will be accessing your website). So, at this point we are ready to talk browsers and to understand why we either have browser options or are stuck with a piece of junk browser in some cases. But before that, one final note about how many of these systems work (and this is really pretty important): The 800 Pound Gorilla In The Room It is tempting to think that good web design for PDAs, cell phones and mixed devices is pretty easy to do and only requires standard HTML/XHTML/CSS type thinking. Unfortunately, this is not quite the case if we really want to control what the user sees and create a pleasant, consistent viewing experience. But more on that later - first: why would we even get the impression that such web site creation is easy? Because some devices, providers and popular websites give that impression since they "look right" when viewed using one of these devices - so when we look at the source code (usually from our desktop computer) we see the same old thing we are used to seeing and thus are led to believe that the same source must be being used for both the desktop and mobile devices. Often (usually?) nothing could be further from the truth. To illustrate how this works with some content providers and particularly cell phone networks (i.e. using a cell phone browser) let's look at a desktop computer analogy: AOL, NetZero, Earthlink and many others out there advertise "download accelerators" or "faster browsing", etc. Is this possible and if so, how? Yes, it is possible, but it is really a kind of slight-of-hand. Here's what happens in a normal browser transaction (very roughly): 1) You type in an address asking for content 2) The address is resolved (that is, it is figured out where the content can physically be located) 3) The content is located and a connection is made to the hosting machine (the handshake) 4) The content is sent to your machine as flat ASCII, generally HTML/XHTML/XML and binary data (for media and images) 5) Any CSS needed is also sent along with any JavaScript or other files 6) Your browser puts all these pieces together 7) You finally see something on your screen In the case of "download accelerators", etc. any or all of steps 3, 4 and 6 above may be mucked with to give the appearance of faster downloads. It should be stressed that nothing makes the data physically download faster (even though the commercials would like you to believe that) - that is simply not possible, that's why I view this as sleight-of-hand. Bypassing Step 3: Some of those providers (AOL, NetZero, etc.) keep track of what people are viewing (not in an identifiable way, but statistically) and then cache popular pages or even entire sites that normally take a long to connect to or might otherwise be slow - this bypasses step 3 in effect since the content you are served may not even come from the physical machine on which the content resides, but may instead be cached on your providers' servers so it loads faster when you request it (think news sites, weather, etc.). Subverting Step 4: Another trick is to subvert step 4 in some way - this is usually done by "smart" algorithms on the providers' servers as follows: When you request a web page through your browser that request always goes through your ISPs servers - the ISP (AOL, et. al.) uses this fact and looks at the page you want and computes which of the following is faster to do A) serve it directly to you exactly as written on the hosting machine, in other words, provide the content in the usual manner or decide that the ISP servers can compress all or part of page you want using some compression scheme and then send it to your browser (this usually requires you to use the special AOL, NetZero, etc. browser you get when you install such software) and then the content is decompressed and shown on your machine. Some of these "services" even down-sample images so they are more compressed when you see them (meaning more grainy and with more JPEG artifacts and possibly wrong GIF colors - but you often have no choice over what you get, they're just trying to help... ) Getting Stuck With Step 6: As mentioned above in the step 4 section, that method generally requires a special browser. Those special browsers may or may not be standards compliant (usually not) and may or may not show web pages correctly (usually not). Thus, when an ISP uses some proprietary compression method or other smart algorithm to serve you data, you have to be using their browser to get their special "features" - this dovetails with step 4 and implies that you get stuck with their browser if you want their so-called "download accelerators" and other related hoo-ha. Happily, on a PC you are not necessarily stuck with their browser, you can generally dial-in or log in using DSL and then choose your own browser and bypass their features and see pages the way they should be seen. What Does This Have To Do With Mobile Devices? So why bother to mention this and why call it the 800 pound gorilla in the room? Almost all cell-phone and most mixed mobile device content providers use similar methods to serve you content that has not been specially designed for mobile devices. The difference is that in the case of most cell phone browsers you cannot change the browser you are using and thus are stuck with whatever translations and alterations are made to the content. In the case of most PDAs the situation is not quite so bad since you can often choose another browser and it's often the browser and not your ISP that makes the necessary conversions and translations to allow you to view normal pages on a PDA. The Browser Problem From Hell Considering all of the mobile device groups mentioned so far, PDAs, cell phones and mixed devices, there is a dizzying array of browsers, capabilities and features (or lack thereof). Even isolating just the PDAs leaves us with a big headache. The problem is fundamentally that the mobile device's are themselves not as mature as desktop machines and thus (no surprise) the browsers for those devices are also not mature, nor are the standards. Summarizing The Problems I would love to talk browsers and standards, but probably you are getting bored (if you've read this far ) and I need to head to work in a few minutes. So, let me directly address some things you asked now that I've muddied the waters. When first I read your request, here is what came to mind: Content: Trying to do websites right for PDAs is tricky and hard Soup: Serving up "acronym soup" on PDAs is easier than serving content Browsers: Another fine mess the web designer is left with from the software developers M3U (Really?): Do you really mean this? Streaming Media: The general answer is "yes" - with a "but"... Resources: Good starting points Content: Websites can most certainly be developed in a manner that they will not be "interpreted" and "translated" so much by either the ISP or the browser, but in general this takes practice and is hard. I mentioned previously that for some big sites it appears that the PDA version and desktop version (and sometimes the cell phone version) are all the same. In truth, this is not the case. A well designed site that is for both desktop browsers and PDA and/or cell phone browsers will check who is trying to get the content (using the HTTP handshake) and then serve up one of two or three versions that is the right version for that platform. For example, desktop websites are designed in the normal way. PDA websites have special designs and layouts and specially encoded graphics and some PDA and cell phone web pages are WAP (Wireless Application Protocol) sites written in WML (Wireless Markup Language) instead of HTML/XHTML. So, you can see that the complexity greatly increases. Soup: The acronyms you will come across are numerous and mind numbing at first (just like HTML/XHTML/XML etc. were at first) but are worth knowing what they mean and represent. Some examples (without explanation) are: WAP, WML, ECMA, MIME, WDP, J2ME, HDML, C-HTML, and on and on... Browsers: The complexities were hinted at above, but there is also some good news: As time goes on there are more and more browsers available for PDAs and cell phones. But this cuts both ways since it also means there will inevitably be too many browsers for a while (just as there were in the early days of the WWW) until some small group becomes standard. Right now Opera and the Microsoft Internet Explorer are pretty popular, but are by no means clear winners yet. There is some convergence taking place in terms of standards for PDA browsers (and less for cell phone browsers since they want everything to be proprietary) which will help designers. For now though, there are several gotchas and it is good to know as best as possible the target audience you are trying to reach and what devices and browsers they will be using. If you're not sure - build your site with your best guess and then check the Apache logs every so often to see what kind of devices are hitting your site. M3U (Really?): Unless this is a format I'm not aware of, I think this is a Winamp playlist file type. It looks like Bruce interpreted it as MP3, which I am assuming is what you meant. His comments stand - that many browsers now can play media. But beware that, for example, an image optimized for a desktop browser is not the same image you would optimize for a PDA (in fact, Photoshop CS3 (and CS2) now have special optimization tools for mobile devices and screens - screen sizes vary widely with the largest I know of for a typical PDA being smaller than 640x480 - most are in the roughly 300x200 range or there abouts). Streaming Media: Again, yes, this can be done, but the file you would stream to a desktop machine is not the same file you would stream to a PDA in general. If for no other reason, then for bandwidth considerations (most PDAs connect using Bluetooth or 802.11[b,g] in practice but can also connect at higher speeds when connected directly to a desktop - but in that case, why both to use the PDA?) Resources: I'm not sure what your background is, so in such cases I always start people out at Wikipedia. The articles may not answer all the questions you need answered, but the external links in the articles generally will. Here are some topics I might take a look at in your situation for more information (just keywords to type in at h**p://www.wikipedia.org) - some of which may not interest you, some of which may: Mobile Browser (great list of various mobile browsers) Embedded Systems Mobile Software Mobile Content Mobile Phone J2ME WAP C-HTML ECMA -or- ECMAScript Mobile HTML Transcoders (these are what compress and reformat content for mobile devices) Windows Mobile Windows CE Palm OS WML Category Lists: h**p://en.wikipedia.org/wiki/Category:Mobile Also - if you own Photoshop CS2 or CS3 (I don't recall if CS has it) check out the optimization for wireless or mobile devices (can't recall what it's called exactly - but something like that) - this is available when you optimize a photo for web. Finally, if you happen to be interested in cell phone devices and want to know more about how that works and you also know Linux, I recommend trying out kannel. I currently have kannel running on my dedicated TCH server for testing (and hope to offer services with it soon). It is free software that allows one to serve web content and do text messaging and have control over these things - technically, it is described as "an open source WAP gateway" - check Wikipedia for more and for the download links if interested. Cell phones and PDA are so entangled that I really felt most comfortable discussing both since often one ultimately hopes to offer both types of content - so I hope this didn't confuse things too much and that it instead helped! Hope this helps and does not bore you to tears! Cheers, Patrick

alley

marks

yelp

Greetings Tamiep, There was a short thread about this a while back - ... The upshot of the above thread is that Thomas brought up a good, sobering question: In the next couple update cycles of Fantastico that contain Joomla updates/upgrades, which path would Fantastico take: A: Take the plunge to the major upgrade and offer Joomla 1.5.x -or - B: Continue to offer the next one or two versions of the Joomla 1.0.{13,14,...} line Either option would be defensible and valid, I think, from Fantastico's point of view. I have been using Joomla 1.5.x on my business development machines and on some of my personal Linux machines at home and like it and am ready to use it for clients and my own web sites; however, as a web designer and reseller to the clients I design for, I have not yet felt comfortable using the new Joomla 1.5.x for my clients or myself. Instead, I decided that I do not have time for (potentially) costly mistakes created in the course of manually installing Joomla 1.5.x (or really any Joomla other than the Fantastico version). My justification for this is: The opportunity cost (mostly in terms of time) of using any version of Joomla other than that provided by Fantastico is higher than I am willing to pay, furthermore, I would like to avoid manual installations, updates and upgrades for myself and my clients to keep the time investment minimal. If I were not a reseller and were only concerned about my own web site (thus only having one website to maintain), then this opportunity cost price point might be very different, perhaps making it more attractive to just manually install and maintain the Joomla 1.5.x upgrade path. But that notwithstanding, it sounds like your comfort level with Joomla may make this scenario moot anyway since you may not even want to attempt a manual install and would (I am guessing) rather focus on getting content up instead of messing around with software! Bottom Line: If I were you, I would probably go ahead and install the Fantastico version of Joomla and then just follow whatever upgrade path Fantastico decides to use, whenever they decide to issue it. But do make sure to update/upgrade your site when new releases of Joomla are available by Fantastico (I forgot to do this for an extended period of time with one of my old Joomla websites and ended up with a site that was so hopelessly outdated that I had to start over again - *augh!*) In general, it has been my experience that setting up "maverick" software installations (anything not offered in Fantastico) and then later trying to use Fantastico to upgrade/update such software creates a huge mess. Often (depending on the software package) it is not even possible to later try and use Fantastico for updates/upgrades. This is particularly true if the version of the software you manually installed has bifurcated significantly from the version offered in Fantastico. At best, this does sometimes work, but is usually too messy and often either breaks many things or fails completely requiring recreating your templates, CSS, data, etc. for whatever software package you're updating/upgrading. So overall I recommend avoiding doing that entirely (and I need to take my own advice as I've got several "messes-in-progress" of just this type ). In my view, then, all of this breaks down as follows: Manual Software Installations (Using the latest and greatest software) Pros: Attractive because of newest features and capabilities Ability to modify software in ways not offered using Fantastico for installations, updates and upgrades Often has the newest security patches, model, etc [*]Cons: Possible problems with updates and upgrades if later attempted with Fantastico Generally best to continue to maintain updates and upgrades manually The "newest security patches/model" (from the "Pros" list above) generally comes with a cost: there are inevitably new bugs, exploits and security holes injected into the new version of the software, so you have to stay on top of all security issues, read the security releases and install the patches Because of the two items above, the opportunity cost to you (usually in terms of time) is thus higher [*] Fantastico Deluxe Installations (Using software available via Fantastico) Pros: "Automagic" installations (Generally much easier than manual installations) Generally very stable software All known security problems are generally fixed in Fantastico versions of software Usually very smooth transitions when updating and upgrading software TCH is great at keeping Fantastico up to date and announcing any "gotchas" or security issues on these forums [*] Cons: Fantastico is often slow as molasses to push new updates and upgrades of software It's like a box of chocolates (vis-a-vis Thomas' remarks) you're never quite sure what you're going to get (or when) - this is especially true when a project branches (for example, for a while Joomla will inevitably continue to have security and minor releases of the 1.0.x series while at the same time the 1.5.x series is also available and new releases of that branch are occurring regularly) As a kind of footnote: For what it's worth, the buzz on the Fantastico website forums is that Joomla will indeed be upgraded to v 1.5.x in Fantastico at some point in the future (see for example h**p://www.netenberg.com/forum/index.php?topic=6260.msg28932#msg28932) but I have not seen anything concrete as to what "the future" means. So, I keep using the available versions and just hoping and praying that the upgrade path provided by Fantastico from Joomla 1.0.x to Joomla 1.5.x will be seamless (even though the changes between Joomla 1.0.x and 1.5.x are pretty major) and that it will occur soon, since there are truly some nice new features and better security model with Joomla 1.5.x. As far as the installation being easier - there are plenty of folks here to help out with the installation part (it's really not so bad). The trickier part of running a Joomla site is the design, in particular the two main files that make up your site's "look-and-feel", the index.php template page (this defines how your website is laid out) and the template_css.css Cascading Style Sheet (which defines how your website looks, so far as colors, etc.) There are places within these great forums to ask exactly this question (how do I "skin" my Joomla website) and there are plenty of folks around who can help and give advice or just discuss how it works (I'm one of those folks who uses Joomla for my personal stuff and also for my clients - I'm certainly no expert, but I love to talk about how it all works and the "glue" needed to make a nice looking Joomla site). My $0.04 on the issue (the extra $0.02 above may be spurious, too much information, or just plain worthless - but is offered just in case it is useful ) Best of luck in your endeavors! Patrick

sun (ahhh... that's better! )

scraper (as in that annoying ice scraper I have to use almost every morning that causes me to be late places since I always forget that the windows will be frozen.... Spring, spring, where art thou?)

trust

nill (Sheesh - all this real world "work" stuff has precluded me playing word games the past few days! Is it Friday yet? )

stray

meld

chairs

collapse

seep

parse

prank

wallet

keet