RE: [MLUG - DISCUSSION] programmers that don't know tarballs?

[Michael <EMAIL:PROTECTED>]

> Ok, crush my sarcastic comment... On that note though, how do you do
> that?  My guess is that it's just a text only browser that your cell
> phone uses, in which case, that's one of the standards we already have
> to meet.

First off you have to realize that some things can work on a cell phone
and some things simply do not. Obviously a website for looking at large
full color pictures will not work on a cell phone. You could convert the
images to grayscale and shrink them but it'd really be something fully
different. For those things you just trim that function out of the phone
accessible version. Anything that is just information or light forms can
work on a phone though. News, email, etc. Usually it just has to be
structured to work on the small or text based device. The first step is of
course to make sure it works okay in Lynx. Then most phones currently use
WML which is a lot like XHTML and not hard to learn the basics of. If your
site outputs in XML it is easy to pass it through XSL to get HTML, WML, or
whatever formatted output. With some trial and error you can make them all
look good. A good HTML design translates pretty easily to a good WML
design. The biggest hassle is addressing the tiny screen space of the
phone meaning that you have to adapt to show bite size clips (when used by
phone) rather than large scrolling /. pages of information.

> You're making the assumption that things haven't changed. People expect
> things free when they're on the web, thanks to the ads paying for things for
> so long. It will take years before anyone really considers donating to
> their favorite sites as a matter of course, in which time, unfunded sites
> will die out.

Things were always free online. Some sites might die out but that just
means the ones that live will waste less of your time. The whole ad banner
thing was a stupid idea from the start. It made sites ugly and caused a
lot of people to think they could get rich quick without a business plan.
A lot of people got rich and are now bankrupt. Running a website of our
own unfortunately can't be a job for all of us but if you have fun and the
costs out of your own pocket aren't to high then your site can do okay.
You just won't be able to buy a Porsche because you made a website off the
family computer.

> Giant sites would be fine.  Yahoo would just start charging for its
> email and other services.  In a decade or so, when the backyard web
> that was mentioned here earlier exists, we'll be hosting our own, so
> this will once again not matter. I am curious how DNS would work on
> such an internet though.  Perhaps you could set it up like current
> email username signups.

Yahoo will probably be fine but we've seen a lot of sites that once seemed
huge crumble. Even Yahoo as you said is now charging for a lot more. For
some people that's fine, for others they'll just find a different
site.. or set of sites to use that are still free. Yahoo will shrink down
to a more realistic size and more realistic business plan and that is not
a bad thing.

I think DNS is going to be a thing of the past as the Internet will not be
URL based anymore. Rather than looking for a resource on a site you'll
look for a resource and take whatever site can provide that resource best.
The search engine will be intergrated into the fabric of the network.
Already a good many people don't even use URL's, they go to their favorite
search engine and type the name they are looking for and when it shows up
in the results they click it. Things will be like that but much more
precise. If you search for 'hot sex mp3' you might get the same sprawl you
get now but if you type in a resource id then only sites with that
resource will show up. That'll be a while though. Hafta wait til P2P and
the web merge into a really working unified concept.

> It's more than bandwidth.  They run apache with perl, php, SSI, and a lot of
> graphics.  It's a fairly large site too, so the bandwidth involved is no
> slouch.  I've heard claims of 10,000 individual users per day, which is
> probably why they're in the $600 category.

*nods* If they have 10,000 users and couldn't raise $600/month their users
really sucked. ;) From my own experience I've found one of the best ways
to motivate donations is to just limit the resource. If you only get 1/6
the money you need to run the way the users want then simply have your
host cut you down to that allowed resources per day and not allow it to go
over that. The fair weather users were get bored and leave and the die
hards will realize what they're lossing and contribute so that things just
sort of equalize.

> The site targeted kids, kids don't have money.  It was a pokemon site
> (those with derogatory remarks about it can KMA).

But kids have parents with money who don't want to listen to their kids
bitch because their favorite site isn't working right because they need
money. For that target audience I'd probably make available some items
they could buy on a regular basis to sponsor the site. Tshirts or
something. To fit the "Mom I just got to have this!" crowd. If you made $6
profit per shirt and sold 100 shirts per month (not unlikely with 10,000
users) you've paid for your site.

> Probably a factor, but again, the users of the site could hardly afford to
> keep it up. Most who did, I gather, could only coax their parents into
> letting them donate a dollar or two.

A dollar or two from enough people helps. Again I'd attack the weak points
to make parents cough up the loot.

> If we could make a limit on popups, say perhaps, one per "on load" and
> have an easy option to shut off the "on unload" I'd even consider
> paying for it if I couldn't find it free online.

I think the key is to make it really easy in every sense of the word. No
geek skills required to set it up or use it and cheap enough that it will
work even for kids and the unemployed lossers like me. ;)

--
To unsubscribe, go to http://mlug.missouri.edu/members/edit.php

Archives are available at http://mlug.missouri.edu/list-archives/