A82: Re: A83: ideas and stuff
[Prev][Next][Index][Thread]
A82: Re: A83: ideas and stuff
inside...
Robert Caldwell wrote:
> First, I would like to apologize for announcing this to more than 2
> lists, but there's some things I'd like everyone to hear.
>
> [[-- Shells --]]
>
> I think it's great for everyone to create their own shells. It gives
> them an advantage over everyone else using their shell, for the fact
> that they know their own stuff. It also teaches them about assembly. I
> believe people don't make a shell for competition, but because they
> don't understand the current shells _entirely_. I emphasize entirely
> because I don't want anyone saying "I know how to use a shell." If
> someone needed a 3D engine built into the shell as a trap or something
> and the shell won't support it, then it would be great that the person
> change the shell for their own needs. It's pretty hard for me to make a
> shell because I can only get on-line to check my mail. I'm trying to
> learn Fargo for the 92 so I can make one that is very easy to use,
> upgradeable, and has control over everything, and also has great
> documentation. Fargo probably is all of this and more, but to me it's
> nothing. I don't understand it at all, and until I make my own shell, I
> won't ever understand it. Don't get me wrong, I still know how to
> upload it to my calculator and play games from ticalc.org, but I don't
> understand how it works _precisely_.
Let's take an analogy here. Look at all the web browsers out there.
There's only two major ones (yeah and tons of minor ones). Isn't in bad
enough for web page designers to make their web pages look the same & good
on both browsers? I know that ticalc.org sometimes struggles with this
problem. What would happen if there were 3, 4, or even more major web
browsers out there? It would be chaos - everyone trying to make their own
web standards. Not that having choices is a bad thing, its that having way
too many choices is sometimes bad. No one is stopping anyone from making
their own shell, its just that I urge caution. I just don't want to see a
lot of useless shells laying around, such as for the 85.
> [[-- Ticalc.org rearrangement --]]
>
> I don't want Ticalc.org to change anything on their page, except for a
> few things. I think there should be another column with a .txt file (PC
> formatted, NOT Unix because I hate reformatting that crap--use PC's edit
> command). The text file should be a full blown documentation of the
> program.
>
> Right now this is what it looks like:
> | added/updated | author's note of file | directory stored
> and the directory looks something like this:
> | filename | size of file | author's note of
> file
>
> I think it should look something like this:
> | added/updated | author's note | .txt documentation | directory
> and the directory:
> | filename | size | author's note | .txt documentation | screen
> shots
>
> the screen shots don't need to be a link to a whole new page, but a link
> to the screen shots page where there are several games on that page.
> Each with 3 to 5 best pictures and the name of the file underneath the
> pictures. The link should be targetted so the user doesn't have to
> scroll through all of them. The pictures should be 2, 4, or 8 greyscale
> to save space at ticalc, and also quick download for some slow
> computers.
>
> The .txt documentation is actually a link to the actual .txt file, so if
> the person wants to download and look at it they can, and if they just
> want to read it they just click on the link.
>
> On the left side I think there should be a checkbox. If the user wants
> to download a specific amount of files they just check the checkbox, and
> at the end of the list should be a "Download checked files" link, so the
> person doesn't have to download the archived file and unzip it deleting
> everything unneeded, they can just download the files they want. Inside
> the file they download should contain the same .txt documentation that
> can be found on ticalc.org. If the main program to run is "main.92p"
> then the .txt file should be "main.txt".
>
> The shells itself should also contain documentation. Along with the
> regular documentation should be features placed into the shell to make
> it unique. If AShell can XOR the whole picture with a faster routine
> then BShell, but BShell can do onboard assembly programming, then those
> should be in the documentation as Features or something.
>
> These are just some of the things I would like to see at Ticalc.org
Actually, what we have in mind is this. Having one page for every file,
that is linked from the filearchive pages. On this page would be
information like author name, author email, long description, screenshots
(if any), a listing of files inside the ZIP with file attributes like size,
a flag if the source code is included in the ZIP or not, and a list of all
the other programs that author has written and links to them. I'm not sure
how much of that we can do, depending on how hard it is to program and how
much resources it takes up. A link to display the .txt file included in the
program is a good idea. Although, our file archive pages are pretty tight
as it is. Screenshots are usually 2 color grayscale, unless the game
contains grayscale, then the max is usually 8. Your checkbox idea sounds
cool, I'll forward that along to the team. About documentation, that is up
to the author of the program. We really don't have the time to look over &
fix the documentation of 4,000+ files.
> [[-- Multiple programs of the same name --]]
>
> Instead of rating these programs as a 4 or 5 star program (which I hate
> since I've seen some good 1 star programs), the documenation and screen
> shots should help the user in their decision. Don't do screen shots of
> the Title screen because if that's the best shot of the whole game then
> the game must really suck (that's what I think when I see a screen shot
> of SimCity and then see a screen shot of those small squares). I'm not
> putting anyone down, but try not to use the title screen as one of your
> shots, that's exacty like putting a good-looking person next to an ugly
> person, the ugly person becomes uglier and the good-looking person
> becomes prettier.
How can a 1 star programs be good? Isn't that an oxymoron?
--
Bryan Rabeler <brabeler@ticalc.org>
File Archives, HTML, and Support
the ticalc.org project - http://www.ticalc.org/
References: