26

Re: NeverTable for Levelset

Perfect. So, I throw the rubbish in the trash. I just checked out your code.

~DEV

27

Re: NeverTable for Levelset

A little note: I don't like HTML 4.1 very much.  I ususally use HTML5 with CSS3.

~DEV

28 (edited by Cheeseness 2012-09-10 21:58:51)

Re: NeverTable for Levelset

shino wrote:

Done :-)

You have started to code a registration page, but I think we should think deeper before implementing such part. Eventually the registration won't be necessary because we will use punbb authentification : it is be the better way to interact with current community database and we rely on spam protection (hmm...) of punbb registration process.

Then we need to think how the level repositories will be organize :
  - How the contributor will upload his new level in the repositroy,
  - How he organize a complete set from some levels he previsoulsy uploaded,
  - Do we handle a vote system on each level / sets to see which one are the most popular ?
  - Do we need comments on a level / a set ?
And so on...

I'd like the new site to be more "web 2.0" friendly, I mean with ajax-style behaviour and modern user interactions as it's done nowadays. I haven't coded in php for years so I'm not totally familiar with those new concepts but I know the basics and I'd like to learn to use them :-)

Good work, shino. It's great to see some design thoughts being floated.

I'd be keen to see an ability to rate/vote for levels, and also review/critique them (with an option for comments on those?).

It's important that something like this be able to support individual levels and have sets/oderings be something any user can create (as though it were a list of related favourites or a "playlist"). This would give people the ability to remix and try different level arrangements fairly easily (this would imply the ability to generate a set archive which could be downloaded - I don't believe that would be particularly difficult though). In the interests of enabling and empowering collaborative set development, I don't think it's worthwhile to restrict set creation to the author of a bunch of levels.

On that note, it might be nice to allow for an ability to link a level with another level to indicate a derivative work (and encourage/support collaboration in that way).

I'd be really keen to see a "adheres to mapping guidelines" flag which users other than the author could set/remove (or vote for?). This would help make levels and sets which would be appropriate for inclusion in a release more obvious.

One other thing I'd be keen to see is an API for retrieving information on levels or sets (returnable in JSON format or something like that).

Are you keen to draw up/draft a schema/data model? I could have a go at it, but I'm not likely to have time this week.


When dealing with "ajax" style behaviour, it's important to focus on not preventing a system from working without Javascript or when Javascript fails. I've got a little experience with some of that stuff that I'm happy to share.

Cheese
==========
cheesetalks.net

29

Re: NeverTable for Levelset

- jQuery
- Rating levels
- Playlist of levels
- JSON Export

Understood.

~DEV

30

Re: NeverTable for Levelset

ht-never wrote:

- jQuery
- Rating levels
- Playlist of levels
- JSON Export

Understood.

Do you really think that jQuery is warranted? That's an awful lot of bloat for the sort of stuff we're talking about.

Cheese
==========
cheesetalks.net

31 (edited by ht-never 2012-09-11 08:42:18)

Re: NeverTable for Levelset

- jQuery
- Rating levels
- Playlist of levels
- JSON Export

~DEV

32

Re: NeverTable for Levelset

Aren't we getting way ahead of ourselves?

I don't want anyone slaving away on features that more than likely will never be used. This isn't saying that I consider them useless, but over the past three years we've probably had no more than a half a dozen people showing their work in one state or another. This current level of mapper activity might even put into question whether we need a level repository AT ALL, not to mention the idea of having features that are appropriate for hundreds of levels and a large, active community.

I understand that this is still "brainstorming" and everything. Still, I'd prefer having a basic, working level repository before all of that.

By "basic, working level repository" I mean a place where people can upload their ZIP files, have other people download them, and receive thumbs up and comments. I realize that such a repository wouldn't even need to be limited to levels, it would just have to allow categorization of the uploaded files.

33

Re: NeverTable for Levelset

I agree with you. Indeed we are working on the database model and on some PHP classes. We are planning to make a "basic, working level repository" for the first.

But we are also planning some nice features that we could add later.

~DEV

34

Re: NeverTable for Levelset

parasti wrote:

I understand that this is still "brainstorming" and everything. Still, I'd prefer having a basic, working level repository before all of that.

In the interests of forward planning, I would be against implementing something "basic" that wasn't designed with an end goal in mind.

Cheese
==========
cheesetalks.net

35

Re: NeverTable for Levelset

I take it you don't believe in iterative development, huh.

36

Re: NeverTable for Levelset

parasti wrote:

I take it you don't believe in iterative development, huh.

lol, I just believe in planning.

Cheese
==========
cheesetalks.net

37

Re: NeverTable for Levelset

Let's think about the project guys smile

P.S.: LOL

~DEV

38

Re: NeverTable for Levelset

I agree with you parasti about the objective of the repository. I know we are a small community, I'm perfectly aware we won't have thousands of users.

The plan to develop basic functionality then enhance the site step by step as long as developers work on it is the way it will be done.

You know when I first started Nevertable it was the same : I did it for fun, to learn PHP , to address a need of the community. It was quite basic at the beginning, then it was enhanced with some fancy stuff (themes or localisation for instance) which are not so much useful but it's nice to get it. The level repository can be created the same way :-)

To sum up we need, by priority :
  - PunBB authentication,
  - File (level) repository,
  - Level constitution (or "playlist") and complete set download,
  - Vote system,
  - Comments,
  - API,
  - Theme support,
  - Get some girls registered on the site.

Using jQuery and ajax technologies is a choice I would prefer for the pleasure to use / learn it. It's not bloat I think, it's modern and it's not slow or accessibility incompatible if we use it correctly and don't abuse. I'll go further : I won't really matter if Javascript is mandatory: seriously, who here doesn't have a JavaScript compatible browser nowadays ?

We'll try to develop with good practices (not sure of the word sorry :-p) PHP 5 object oriented and in an open source spirit of course, so the community can follow and criticize (and contribute) as much as it want since the beginning. It starts great I think with your constructive reactions :-)

39

Re: NeverTable for Levelset

- Get some girls registered on the site.

For the first.

~DEV

40

Re: NeverTable for Levelset

shino wrote:

Using jQuery and ajax technologies is a choice I would prefer for the pleasure to use / learn it. It's not bloat I think, it's modern and it's not slow or accessibility incompatible if we use it correctly and don't abuse. I'll go further : I won't really matter if Javascript is mandatory: seriously, who here doesn't have a JavaScript compatible browser nowadays ?

I think the point is more "What justification is there for alienating people who choose to browse the web with Javascript turned off?" I seem to recall the community wrestling with this issue when the current neverball.org site.

jQuery degrades nicely, but has a pretty large footprint if all you want to do is have some dynamic ajaxy type stuff, and I imagine that the majority of its functionality would go unused, so the term bloat applies IMO.

I'm happy with that priority listing, providing that when we're ready to deploy something, it's not something that needs redesigning down the track because features we've already identified as being on the roadmap don't fit. I've got nothing against unforeseen featires/developments, but if there's something we can identify now that we eventually want, it seems silly (and wasteful) to not design the current system with those in mind.

- Get some girls registered on the site.

What makes you think we don't already have some wink

Cheese
==========
cheesetalks.net

41

Re: NeverTable for Levelset

IMHO, I suggest to use less JavaScript. I think we should use HTML5 to do what jQuery actually do. I can make very nice designs with CSS3.

~DEV

42

Re: NeverTable for Levelset

ht-never wrote:

IMHO, I suggest to use less JavaScript. I think we should use HTML5 to do what jQuery actually do. I can make very nice designs with CSS3.

Yeah... HTML5 isn't really capable of doing the kind of content pull requests that Javascript can (that's why Javascript exists).

Cheese
==========
cheesetalks.net

43 (edited by ht-never 2012-09-11 12:44:39)

Re: NeverTable for Levelset

Lot of what we are going to do it's possible with HTML5.

~DEV

44

Re: NeverTable for Levelset

ht-never wrote:

Lot of what we are going to do it's possible with HTML5.

Oh, definitely. Just not the "ajax-style" stuff Shino mentioned.

Cheese
==========
cheesetalks.net

45

Re: NeverTable for Levelset

This is not absolutely true. Ajax is versatile to do more complex websites. In our case, we can easily design those "cute decorative elements" in a perfect ajax style with HTML5

~DEV

46

Re: NeverTable for Levelset

I probably did advocate against using JS for neverball.org. Honestly, I have no idea why. There are awesome things you can do with JS that can make a website much more pleasant to use. I say, do whatever you want as long as it doesn't make the site completely useless to anybody.

47

Re: NeverTable for Levelset

JavaScript is not Ajax. I think we should use less JavaScript, not absolutely delete it from our project.

Anyway, I implemented these class:

  • User

  • Set

  • Connection

~DEV

48

Re: NeverTable for Levelset

parasti wrote:

I say, do whatever you want as long as it doesn't make the site completely useless to anybody.

That's pretty much where I'm coming from. Do as much JS as people are keen to do so long as it degrades nicely when things go wrong or when JS isn't available/enabled.

ht-never wrote:

This is not absolutely true. Ajax is versatile to do more complex websites. In our case, we can easily design those "cute decorative elements" in a perfect ajax style with HTML5

ht-never wrote:

JavaScript is not Ajax. I think we should use less JavaScript, not absolutely delete it from our project.

*facepalm*
The J in "ajax" stands for Javascript. The term "ajax" does in no way denote "cute decorative elements". The techniques we're talking about revolve around using Javascript (or some other client side scripting language) to pull small pieces of content (usually provided by some server side scripting language), which is then inserted into the page using Javascript.

Cheese
==========
cheesetalks.net

49

Re: NeverTable for Levelset

Ajax stands for "Asynchronous Javascript with XML". I can't see any "with XML" and yes, I know how it works.

I'm not against to the use of JavaScript, why on earth should I do?

~DEV

50 (edited by Cheeseness 2012-09-11 13:47:16)

Re: NeverTable for Levelset

ht-never tells me that his "HTML5 can do ajax" comments were a result of thinking that Shino was talking about "visual appeal". I'm not quite sure I can make that cognitive jump, but that clarification may help to make some sense of this bizarre conversation.

For additional clarification, I do not subscribe to the term "ajax". It's a buzzword for techniques and technologies that were being used long before the term's appearance. I don't think that introducing the extraneous overhead of XML is valuable in most situations, though if we were to implement an API, it would probably make sense to just expose  whatever stuff we had set up for asynchronous responses.

Cheese
==========
cheesetalks.net