Your Threads are IRRITATING & DIFFICULT to navigate

Discussions

TSS feedback: Your Threads are IRRITATING & DIFFICULT to navigate

  1. I know it is difficult to write and mimic a newsreader client. But something has *got* to be done to make the readers' experience better when it comes to perusing TSS threads. So difficult and "freaking" irritating to identify in whose response a current posting is submitted. This becomes a pain when you read something interesting and then have to go all the way to the top to navigate to the correct responses. Aaaargh!!! (So much for patterns!)

    May I suggest that you use plain XML to display all your thread postings. That way you have automatic tree-view plus the ability to Style Sheet it at will? No? What ' say?

    Regards

    Abdullah

    Threaded Messages (22)

  2. Threaded messages[ Go to top ]

    Hi Abdullah -

    We will be changing the forum in the future.
    We currently added a couple of UI features to the threads for the moment.

    Here they are:

    - Threaded Replies area after the initial message
      Click on the reply that interests you to be taken there
    - When reading a message itself
      . Click on the "in response to Message #XXXXX" to view the parent message
      . Click on the white up arrow, to go back up to the Threaded Replies view
      . Click on 'Reply' to reply to this particular message

    Thanks for your ideas, changes will come.

    Dion
  3. Threaded messages[ Go to top ]

    I appreciate that you guys keep working on this, but there's 100 different websites out there that implement a discussion board in a very good way. Just look at slashdot. We don't need the moderation, but the UI is really well done. Messages in reply to another message are nested, so you don't have to click around to find out the reference....
  4. I totally agree, I think this forum software is the result of an experiment with J2EE and EJB and not a serious attempt to design a real forum. This is the main reason I don't participate as much as I'd like. Now that there are tons of users here, it makes sense to use real forum software, preferrably something that already exists and is working well.

    Having a proper threaded display is absolutely mandatory. I bet theserverside is losing a lot of potential users because of this.
  5. Maybe the community can do better?[ Go to top ]

    Quite possible. And I must say that this site exhibits sufficient wierdness compared to other sites that I fear it could damage the impression people get of J2EE. Like earlier, when images wouldn't load depending on your client configuration? Or the useless search?

    How about a contest to reimplement theserverside.com? Publish the database schema, and give 2 months to submit a working .ear file. Winner gets their (or their company's) name on the redesigned site.
  6. Maybe the community can do better?[ Go to top ]

    I don't see the need to reinvent the wheel. There are lots of forum based products out there, one of the most popular ones is the software used to do the JDO Centeral forums (I don't know what it's called). I think it's based on Perl. It works really really well.
  7. Maybe the community can do better?[ Go to top ]

    Shouldn't a portal/forum that discusses server-side Java/J2EE be implemented in said technology and not PERL or PHP?
  8. Maybe the community can do better?[ Go to top ]

    I don't see why a J2EE discussion forum has to be based on J2EE just because it is a J2EE discussion forum. Most J2EE developers like to thing that J2EE is a better technological solution than PERL or PHP for such a forum. That should be the reason for using J2EE.

    Regarding your contest idea, I personally think it's a nice thought, but not a practical one. TSS can't say "a bored community member couldm, on his spare time, build a better TSS in two months than our dedicated full-time team was able to build in the several years we've been running". What would that do to their J2EE experts status? The middleware company's pet-store report fiasco has allready damaged it.

    I'm guessing TSS is going to stay with a home-grown forum system based on J2EE. So let's use this thread to list the features we'd like to have on TSS. My list is:
    - Ability to watch threads, authors, etc (beyond watching threads you post to).
    - Some sort of rating system per-thread or pet-author.
    - A better (ahm, a working) search engine.
    - Hierarchial display of threads.
    - Quotation features: at least the ability to quote the message you are replying to.
    - A seperate message style for code (with some rarely-used activation sequence, unlike the JDC's "[i]").
    - Ability to correct a posted message for some predefined time period.

    That's all I can think of off the top of my head.

    Thanks is advance to the TSS guys for their excellent work.
    Gal
  9. Why reinvent the wheel? I prefer to use a well known, widely used, bug free, feature rich forum written in Perl than one with less features, more bugs, harder to use, etc. written in Java. Besides, the language used to write the thing should be transparent to the user. It doesn't matter. Why waste time improving something that is so far behind it'll be impossible to catch up without a major development effort?
  10. Why J2EE?[ Go to top ]

    Guys,
     
      The reason this site was first written in J2EE is because at the time ('99) there weren't any decent off the shelf discussion packages, and also because J2EE at the time was an unproven technology. As a J2EE community, being implemented in J2EE was a big deal and important to our credibility as a J2EE site.

      The reason the site hasn't grown too much in the last few years is because we had extremely limited resources, and we applied those resources to content, which I think was the right thing to do as it grew the community.

      In the last 8 months or so, things changed. TSS started selling advertising and is now drawing in a healthy revenue and now we have a full time Chief Architect/Developer (Dion) who is spending his time working on new features.

      Today, with J2EE clearly the winner, the need to validate it via running files with .jsp extensions may be more of a 'nice to have'. It is a tough decision. How hard core would the site be if it ran on perl? Why is perl more palatable than .asp? Where is the proof that J2EE is portable if we run TSS in a cluster of appservers where our code is mostly third party or non-java?

      We are listening to you and are considering your points.

    Floyd
  11. Why J2EE?[ Go to top ]

    If there aren't any open source message board projects (I don't know I haven't looked) then I think no one is going to criticize you for using an existing system developed in Perl. The database doesn't have to be written in Java so why would the message boards?

    I understand why it was written in Java in the beginning, but it's never too late to make a change. I truly believe that if the software was more useable, we'd have more user activity here. And that'd be a good thing.
  12. forum features[ Go to top ]

    Getting off the pointless flamewar,

    I think there are several things about the forums that can be improved. The new changes are generally OK. I think a feature that could be added is the ability to sort the threads. In particular interested in being able to see the most recently-posted-to thread float up to the top of the list. Also in the list, it would be nice to see the name of the last person who posted to the thread.

    Someone else mentioned Slashdot. Can I add a '-1' to that? I hate the Slashdot threading system. I find it unnessarily complex with all that "2 replies beneath your threshold" stuff and I often don't see any sense as to why something is below the threshold and another thing not. It's just an unneccessary mess. Using a threading diagram at the top of the thread like TSS has now is perfecty sufficient.

    Some sort of limited quoting mechanism would also be nice.

    regs
    scot.
  13. Maybe the community can do better?[ Go to top ]

    <quote>
    Shouldn't a portal/forum that discusses server-side Java/J2EE be implemented in said technology and not PERL or PHP?
    </quote>

    That's like saying the building that houses the monthly meeting of the Amalgated Union of Cheese Producers should be built from cheese.
  14. Maybe the community can do better?[ Go to top ]

    Tim,

    Your cheese analogy is a poor one. I hope you have a better grasp of logic in your code.

    I think that the building that houses the "Steel Lobby" should definitely be made of steel, just as TSS should be written in J2EE.
  15. Maybe the community can do better?[ Go to top ]

    What a load of nonsense.

    <quote>
    I think that the building that houses the "Steel Lobby" should definitely be made of steel, just as TSS should be written in J2EE.
    </quote>

    So you would prevent them meeting in a stone or wooden building simply because they are the "Steel Lobby"?- I think you would be laughed out of town if you suggested that.
    __Use the best tool for the job, don't reinvent the wheel.__
    And don't be blinded by your prejudices. I use J2EE to write complex business systems, but I don't expect it to make my toast for me.
    Does that make J2EE weak because it cannot make toast? Of course not.
    Is a screwdriver a bad tool because it cannot hammer in nails? Of course not.
    If J2EE is the best tool for a forum use it. Although I think it would probably be a lot easier just to use the slashcode or some other similar (free), tried and tested system.
    IMO the priority here is to have a performant and highly useable system that enables the community to communicate well. That's the bottom line.
  16. Maybe the community can do better?[ Go to top ]

    Wow. I'm glad I don't work with you.
  17. Race, why don't you give us all a break and keep your witty remarks elsewhere? Tim was making a valid point, whether you agree with him or not (I happen to agree). The fact that you would rather fall back to personal remarks rather than argue the point shows more about you than about him.

    Gal
  18. Agreed.
  19. Gal,

    I hope my last comment wasn't too witty for you.
  20. Maybe the community can do better?[ Go to top ]

    <good sense>

    1. J2EE technology can be used to make Internet web sites. TRUE (I know it can do so much more, blah, blah blah)

    2. TSS is an Internet web site devoted to J2EE. TRUE.

    3. If J2EE were to cease to exist, TSS would cease to exist as we know it today. TRUE (they might still exist but could choose cheese or toast for forum subjects instead)

    4. As an promoter of J2EE and facilitator of J2EE discussion, it is my OPINION that TSS enhances the credibility of J2EE technology by using it.

    </good sense>


    <analogy so tim can understand>

    If I go to the Ford dealer and all of the salesmen drive Chevies, they have failed to add any credibility to the products that they sell.

    </analogy so tim can understand>
  21. Race,

    TSS is not a J2EE salesman. I don't want them trying to convince me to use J2EE because they have to. In fact, I think a much more usefull and rare commodity is to have them try and convince me not to use J2EE (or specific parts of it) when they are not suitable. Everybody talks about EJB. Few mention that it is a complicated, high-weight architecture that is a major overkill for many projects.

    If J2EE is suitable for making a web-based forum system, TSS can go ahead and use it. If perl is currently more suitable (even if only because there are better off-the-shelf perl-based forum systems) I would have no problem with TSS using perl. I would much prefer to have a good forum service (TSS now being about the worst I've ever seen in just about any category, excluding the excellent user community).

    While we're at it, I also didn't like that "portabillity cluster" idea. It's a cute buzzword for J2EE enthusiasts, but I certainly wouldn't do it on a production level, widely used system. I don't even know what kind of impression it is supposed to make. My impression was that either J2EE portability is not very good, or the TSS development team didn't do a very good job. For a long while TSS had shorter uptimes than my personal Win2k box at home. And I shut that off every night... Of course J2EE portability doesn't actually mean running several different servers in one cluster. So the whole idea seems kind of silly to me. I would never consider running several different servers in one cluster, and I doubt any sane developer would. IMHO this is just another case of giving up quality of service for big titles and buzzwords, in the name of the "community".

    Gal
  22. Maybe the community can do better?[ Go to top ]

    Hi Race - An ad hominen (http://www.nizkor.org/features/fallacies/ad-hominem.html) attack is always fun to read, and not something I've seen a lot of since junior school, so thanks for your replies.

    Anyway, in response to your point:

    <race>
    <analogy so tim can understand>
    If I go to the Ford dealer and all of the salesmen drive Chevies, they have failed to add any credibility to the products that they sell.
    </analogy so tim can understand>
    </race>

    Gal's reply to this is valid - TSS is _not_ a J2EE salesman. To make an analogy with Aspect Oriented Programming, (and looking at my previous analogy) the nature of the meeting and the how the room are constructed are "cross-cutting concerns" - you are making a very common (and easy to do) semantic error in assuming they represent the same problem domain simply because some of the "labels" (words) we are using for the things in each problem domain are the same (confusing the fact that the meeting room is "constructed" and the people in the room do "construction").
  23. Maybe the community can do better?[ Go to top ]

    So now you have resorted to the use of those fancy latin words. I guess you win.