[beta.a-m-v.org] Hey, we're semi-official

[I Fight For The Users]

http://beta.a-m-v.org

No great changes here except the domain name. I still want beta.animemusicvideos.org, but I need to talk to more people for that to happen.

Actually, there is one nice change. You can drag cover images to reposition them, which is a lot nicer than typing in CSS background-position directives. Try http://beta.a-m-v.org/videos/85uutbxhpm ... 1n6dr/edit for an example. (No, you won't be able to save your changes -- unless you log in as Scintilla.)

---

Next up: I've hit a block with the approach I'm taking. I want direct, simple editing of all data -- no multi-page processes or long lists of checkboxes. For stuff like image positioning and event positioning, however, this often means "page editors powered by Javascript", which in turn implies that you need some way to synchronize state being manipulated by Javascript with what's eventually sent back to the server. I've been doing all that synchronization manually, and it sucks to do that.

Other people have told me that they want fewer page loads. I've been told by AisuzuZwei, for example, that it would be nice if clicking "Edit video information" (or any other edit link) did not result in a page load, but instead replaced all read-only areas with editable content areas. I agree that this is indeed useful, but it is not easy to accomplish with the current setup.

I have therefore decided to separate view from application. The upside of this is that beta.a-m-v.org will (in a few weeks) require only one page load; once you load the page, you can get anywhere in the catalog. (You will, of course, be able to enter the catalog at any point; e.g. going to http://beta.a-m-v.org/~trythil/ always will put you at a video information page for a crappy Evangelion video.) The downside is that beta.a-m-v.org will do absolutely nothing with Javascript disabled.

I can go on and on about how much I think that downside sucks, but Web development is very much an art of Sucks Less, and I think it's the least bad option for everyone. I'm happy to go into more detail about the technicals behind that decision if anyone's interested.

[Chained(E)Studio]

Is that going to be the homepage? >.>

[Nya-chan Production]

http://beta.a-m-v.org

No great changes here except the domain name. I still want beta.animemusicvideos.org, but I need to talk to more people for that to happen.

Actually, there is one nice change. You can drag cover images to reposition them, which is a lot nicer than typing in CSS background-position directives. Try http://beta.a-m-v.org/videos/85uutbxhpm ... 1n6dr/edit for an example. (No, you won't be able to save your changes -- unless you log in as Scintilla.)

---

Next up: I've hit a block with the approach I'm taking. I want direct, simple editing of all data -- no multi-page processes or long lists of checkboxes. For stuff like image positioning and event positioning, however, this often means "page editors powered by Javascript", which in turn implies that you need some way to synchronize state being manipulated by Javascript with what's eventually sent back to the server. I've been doing all that synchronization manually, and it sucks to do that.

Other people have told me that they want fewer page loads. I've been told by AisuzuZwei, for example, that it would be nice if clicking "Edit video information" (or any other edit link) did not result in a page load, but instead replaced all read-only areas with editable content areas. I agree that this is indeed useful, but it is not easy to accomplish with the current setup.

I have therefore decided to separate view from application. The upside of this is that beta.a-m-v.org will (in a few weeks) require only one page load; once you load the page, you can get anywhere in the catalog. (You will, of course, be able to enter the catalog at any point; e.g. going to http://beta.a-m-v.org/~trythil/ always will put you at a video information page for a crappy Evangelion video.) The downside is that beta.a-m-v.org will do absolutely nothing with Javascript disabled.

I can go on and on about how much I think that downside sucks, but Web development is very much an art of Sucks Less, and I think it's the least bad option for everyone. I'm happy to go into more detail about the technicals behind that decision if anyone's interested.

What about the mobiles, mobile subdomain?

Why do we even need stuff like image positioning? Isn't it more convenient to do it locally and upload the result? I can understand cropping, but positioning? Really? It's tough to do it precisely anyway.

The JS approach sounds good, but I can't stop worrying something will go wrong somewhere. Reminds me a bit too much of notorious Japanese webs completely made in Flash (and thus completely non-functional). I know there's a difference and that this can work great, but... the feeling!

Is that going to be the homepage? >.>

If it were IFFTU's way, I think it would happen - I have learned that over time (no pictures, no colors, if it were by his, no background colors as well, maybe). But I suppose there will be some design stuff going on later.

[CodeZTM]

I'll be honest (and I'm not trying to be difficult, I'm just voicing my opinion here), I'm still not a big fan of the menu at the bottom of the screen. I feel like the main stuff that I use on the Member's Main Page is going to be less easily accessible. I still absolutely love this menu design that Phant designed. Not so much on the other stuff, but the menu by itself is easily visible and well organized, easy to read and still in a somewhat similar format to what we have now.

[BasharOfTheAges]

What about the mobiles, mobile subdomain?

Need a face stabbing emote - right here. Mobile pages existed for hacked together mobile browsers on feature phones that couldn't zoom or easily pan. The have no place on the modern internet except to cause frustration. See: http://www.xkcd.com/869/

[I Fight For The Users]

What about the mobiles, mobile subdomain?

What about them? The current .org doesn't work well on a mobile device anyway. (Or, if it does, whatever media detection it does isn't working for my N9.) Use cases on mobile devices are different and therefore tend to be served better by different presentations; they can be addressed after more fundamental issues.

And, yes, something like m.(domain) is a pretty common convention these days.

Why do we even need stuff like image positioning? Isn't it more convenient to do it locally and upload the result? I can understand cropping, but positioning? Really? It's tough to do it precisely anyway.

Because people asked for it.

The JS approach sounds good, but I can't stop worrying something will go wrong somewhere. Reminds me a bit too much of notorious Japanese webs completely made in Flash (and thus completely non-functional). I know there's a difference and that this can work great, but... the feeling!

I don't like it either, but it really is the path of least resistance to accomplishing what people have said that they'd really like to see. I hate describing this sort of stuff on web boards; catch me on SynIRC in #grommet if you want the rationale.

Is that going to be the homepage? >.>

If it were IFFTU's way, I think it would happen - I have learned that over time (no pictures, no colors, if it were by his, no background colors as well, maybe). But I suppose there will be some design stuff going on later.

1. You do not separate "design stuff" with "programming stuff". They occur simultaneously, and if you look in the source history for this project, you will see that that is indeed the case.

2. That homepage is incomplete, and that is the reason why it is sparse. There is no benefit to ornamentation when fundamental sections have yet to be constructed. (Which, incidentally, are why such additions are called ornamental.)

3. What is this "no pictures" crap? Did you see the mockups? (Did you see what's already there?) Video-related images are precisely the reason why little ornamentation exists.

I still absolutely love this menu design that Phant designed. Not so much on the other stuff, but the menu by itself is easily visible and well organized, easy to read and still in a somewhat similar format to what we have now.

I don't love it; I think it's lazy work. All he did is shove a bunch of actions into a hierarchy.

I suspect the reason you find the current mechanism "more easily accessible" is habituation. But consider interactions:

1. The best-case scenario for getting to the "new video" page, in the current layout, is click, travel, click. That's assuming that you know that "New Video" is stashed under "Editors". If you don't, it's going to be a while; throw in a lot more clicking and mouse travel. You can configure nodes of the menu to be kept expanded, but that's even more interactions.

2. The best-case scenario for getting to the "new video" page (indeed, any other leaf) in my design is one key press, mouse travel, one click. If you're not used to it, it's (scroll wheel / move mouse to scrollbar, drag), find, click. However, there is no hierarchy to remember, and the site map is a fixture, easily located. (That site map design is also a convention adopted by many other websites, further increasing its utility.)

For other actions, such as searching for events, videos, or other editors, it can be even better:

* Want to go to an editor's profile? Just type http://beta.a-m-v.org/~(editor name) in the address bar. You don't have to interact with any page widgets, just your browser.
* Want to go to an editor's video? Type http://beta.a-m-v.org/~(editor)/(title). Ditto.
* Don't like the address bar, or don't have one available? That's okay too; type whatever you want to find in the search box. It's then my responsibility to tune the search index so that you have a good chance of getting what it is you want to find. (Search doesn't work right now because I'm prototyping ways to make it good. Also, said JS rework.)

The first two interactions require habituation, but it's habituation that can be taught by having the site generate URLs in those formats.

[I Fight For The Users]

Because people asked for it.

I want to qualify that: just because someone asks for something, that doesn't mean it's a good idea. However, those people who asked for it told me why they wanted it, showed me demos of that drag interaction in other sites (i.e. Facebook), and from there I could see that there is, in fact, quite a bit of value in providing that sort of function. It gets even better when you think about how it could be applied elsewhere. (For example, videos on profiles are shown with thumbnails. Why not make those customizable too?)

[CodeZTM]

2. The best-case scenario for getting to the "new video" page (indeed, any other leaf) in my design is one key press, mouse travel, one click. If you're not used to it, it's (scroll wheel / move mouse to scrollbar, drag), find, click. However, there is no hierarchy to remember, and the site map is a fixture, easily located. (That site map design is also a convention adopted by many other websites, further increasing its utility.)

For other actions, such as searching for events, videos, or other editors, it can be even better:

* Want to go to an editor's profile? Just type http://beta.a-m-v.org/~(editor name) in the address bar. You don't have to interact with any page widgets, just your browser.
* Want to go to an editor's video? Type http://beta.a-m-v.org/~(editor)/(title). Ditto.
* Don't like the address bar, or don't have one available? That's okay too; type whatever you want to find in the search box. It's then my responsibility to tune the search index so that you have a good chance of getting what it is you want to find. (Search doesn't work right now because I'm prototyping ways to make it good. Also, said JS rework.)

The first two interactions require habituation, but it's habituation that can be taught by having the site generate URLs in those formats.

Ok, the site urls are nice. That alone makes me enjoy the new system.

Still, can you provide me an example of a site that's actually using menus at the bottom of the page? At the same time, is it going to remain what is is now text/font wise, or is there going to be some design manipulated into it?

Also, you mentioned "one key press, mouse travel, one click". What do you mean by One Key Press? There's a key that takes directly to the menu?

[I Fight For The Users]

2. The best-case scenario for getting to the "new video" page (indeed, any other leaf) in my design is one key press, mouse travel, one click. If you're not used to it, it's (scroll wheel / move mouse to scrollbar, drag), find, click. However, there is no hierarchy to remember, and the site map is a fixture, easily located. (That site map design is also a convention adopted by many other websites, further increasing its utility.)

For other actions, such as searching for events, videos, or other editors, it can be even better:

* Want to go to an editor's profile? Just type http://beta.a-m-v.org/~(editor name) in the address bar. You don't have to interact with any page widgets, just your browser.
* Want to go to an editor's video? Type http://beta.a-m-v.org/~(editor)/(title). Ditto.
* Don't like the address bar, or don't have one available? That's okay too; type whatever you want to find in the search box. It's then my responsibility to tune the search index so that you have a good chance of getting what it is you want to find. (Search doesn't work right now because I'm prototyping ways to make it good. Also, said JS rework.)

The first two interactions require habituation, but it's habituation that can be taught by having the site generate URLs in those formats.

Ok, the site urls are nice. That alone makes me enjoy the new system.

Still, can you provide me an example of a site that's actually using menus at the bottom of the page?

* http://www.apple.com (site map)
* https://github.com (site map)
* http://www.engadget.com/ (used for ancillary links; I'll get back to that)
* https://twitter.com/ (meta-links)

If you're going "but wait a minute, all the examples you gave put secondary links at the bottom!", then you're right. The same applies here.

I don't think stuff like "new video" is important enough to deserve top billing. (Maybe it does. I've asked for usage metrics on the current .org but haven't gotten them yet.) Either way, the important stuff that I have been able to identify is:

1. Log in.
2. Sign up. (No sign up page yet, I know.)
3. Search the database.

Item #3 is the big one, which is why that search box eats up so much of the top. You should be able to get to any video, any event, any profile, any user-generated content from a single point. (Should I find a way to make phpBB behave, yeah, that may include forum threads.) The best way to do that, I think, is incremental search: as you type, you get suggestions. Properly executed, it's a very fast and satisfying feedback loop.

Fast, relevant incremental search on the Web is actually pretty hard to do, especially when you're searching a large heterogeneous database, but I think I can make it work. The important part insofar as using the site goes is that you can assume that you can type in anything (e.g. "CodeZTM", "Playground Love", "AWA Pro") and get back relevant information within (let's say) 100-150 ms.

At the same time, is it going to remain what is is now text/font wise, or is there going to be some design manipulated into it?

The typefaces have gone through a bit of iteration; I'm happy with what they are now. The front page does not show any body text, but something like http://beta.a-m-v.org/~jasper-isis/Frost%20and%20Flames may give a better example.

I've heard that the typefaces are too thin on Windows XP with ClearType enabled, but I haven't been able to get a screenshot (or, probably better, camera capture of the screen) of the problem. I find the typefaces to have acceptable width on Windows 7 w/ ClearType enabled, OS X 10.6.8, and Ubuntu 12.04.

Also, you mentioned "one key press, mouse travel, one click". What do you mean by One Key Press? There's a key that takes directly to the menu?

The End key does, because it takes you to the end of the page.

[I Fight For The Users]

FYI, please feel free to stop by #amv or #grommet on synIRC. I think the real-time nature of IRC is much better for conveying information than the chunky conversation required by forums.