Thanks for the compliments
- Skip the "guest:guest" login and just auto-login as guest. Similarly with the logout being there if you're only a guest.
I'm afraid this would require quite a thorough rewrite of its authentication/session system.
- It seems to require use of the back-button for navigation, rather than having links.
Depends, really - in category view, you can go "up" and "down" in the category tree with built in navigation links, and everywhere else, you can always start over by clicking the top "logo", which points to the index (except in the index - we all know self-linking is bad).
Also, a point: why do browsers have back buttons?
- Personally, when I click the name of the object I don't expect it to start downloading, but to take me to the info. Maybe have a link that says "download"
I battled with this myself. On one hand, I like the current logic of it. On the other, I realized the possible bizarreness of the UI in that respect. I thought about changing it, but neglected to do so. I could be persuaded to rewrite the file lists...
- When creating a new account, it's not actually clear what the process is doing or why it's being done. Why is it dealing with PM messages? To ensure the user is a tt-user? It's not too clear right now what the process is about, it confuzzled me (though did work when I decided to press the button
The PM part of the registration is indeed in place solely for the purpose of weeding out those without accounts here. (I wrote about this above the link that takes you into the registration PM.)
Basically, it's 4-part process, starting with the registration form:
#1 SERVER: does nothing yet
#1 CLIENT: inputs username&password
#2 SERVER: saves username & password into user database as an inactive account, generates and saves an activation key
#2 CLIENT: is requested to click the PM link. Clicks the link.
#3 SERVER: a FORM (POST) sends three INPUT (HIDDEN)'s to the tt-forums PM module. They contain the recipient (you), subject and message body.
#3 CLIENT: clicks the activation link
#4 SERVER: gets the activation details from $_GET. Compares to database. If correct, activates the account, logs the registration and fills in a login form.
#4 CLIENT: can now login.
Back in the days of phpBB2, when I first used this method of 3rd party account verification with phpBB, it actually succeeded in sending the PM and it was rather a clever system. Now there are some hardcoded and pretty solid measures in place in phpBB to sniff when incoming data is actually from the forum itself. I did some research and it appears they were introduced pretty recently, it could be that this would work flawlessly with some earlier versions of phpBB3.
Anyway, I'm quite satisfied personally with how this works, bearing in mind it is a really useful thing to have even if it is slightly cumbersome to the user.
Maybe ask owen to if there's a way to make an exception to your website on the spam filter or something.
There is, but it requires digging into source code and commenting out some stuff - I'd rather he not have to do that.
- Logged in, there's an "edit" next to the "categories" at the top, but this does nothing.
- The "edit" in the categories should probably say "add new file" as there's not actual editing of any existing content.
Similarly there is an edit button when viewing someone elses content, even though I can't edit it.
Now, this is to do with the "edit mode" philosophy of the... edit mode.
I don't know if you noticed, but when you click "edit" in the front page, you are in edit mode in the category and file pages as well.
Basically, the site can be browsed in two modes: normal, and edit mode. In the former, you have a pretty much identical UI to the guest:guest login. You can browse, but cannot change anything. In the latter, you get form fields to edit everything you have clearance to. (In the case of the category view in the front page, nothing.)
I've thought about moving the normal-/editmode links next to the logout link to make the distinction clearer. Let me know what you think.
- For file type, where it says "source", "spites" etc, I'm not sure if those are what the things are normally called (if so, ignore this), but I'd be more inclined toward: "3d model" and "texture"
As I understand it, .blend files and their proprietary cousins are basically text files with coordinates and identification for 3D shapes (well, 2D planes for constructing 3D shapes), and texturing info. So basically, in layman's terms, it's "source code" for a 3D object. That's the rationale for my calling .blends "source".
Again, this is something I've thought about before, and decided against "3D model", "model file" or such, because those made me think it was the source including
textures, which this specific option should not include.
How does someone actually edit current content to upload a newer version?
Navigate to a file in edit mode
and fill out the form, including the optional bits. You'll figure it out.
(And remember you can only update files where you are the owner.)