Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment feedback, both negative and postive (Score 2) 2219

I'm a long time reader of the site, and I've just had a quick look at the beta site. The first word that jumps to mind is "awful", now let me explain why:
  1. 1) The information density is way too low as compared to the classic site. I'd need to scroll about considerably more just to go down through the comments. Specifically:
    1. 1/ way too much space dedicated to the margins. I can set margins myself thankyou. Don't waste my screen real estate.
    2. 2/ right margins are incredibly excessive, especially with nested posts. Yes, the classic side did indented right margins as well, but it didn't waste that much space.
    3. 3/ The right column is completely wasted space. The classic theme allows for the space below the column to be used. The beta site wastes it all until the end of the page. Not good. I have to narrow my screen enough to make it go away.
    4. 4/ there is too much spacing in the vertical flow. tighten it up.
  2. 2) The titles of each post are not very distinctive. It's hard to see where one stops and where one starts. This makes it harder to scan through the comments looking for the stuff that interests you.
  3. 3) where are the story tags?

On the positive side:

  1. a) the responsive theme is nice. I like the menus and how you adjust based on my screen width - just keep in mind the wasted space I mentioned above.
  2. b) the responsive menus are nice. they hide some things that deserve to be hidden, but are still available if you want them.

These comments are purely on the visual aspects. I've not yet tried the other functionality, nor do I want to when the current beta visual outlook makes my eyes bleed.

Final comments - Consider your audience - by and large, they are mostly techies. They are used to dealing with information dense screens of information and want things quickly. They don't have time to waste scrolling up and down. Obsurdly narrow comment columns are just about the worst thing you can force someone to look at. Don't do it. With the classic site, I can set the widths to what I want and read at my comfort using half of my screen. The beta site makes me waste a whole screen. It doesn't matter how many screens we may have, but one of them is not going to be dedicated just to one website. No way.

Of course, no one likes change - look at how much flack facebook gets everytime they update their visuals - but if you can correct most of the visual oversights and errors you have added to the beta site - if you make the information as accessible as the classic site, perhaps the backlash will be reduced to a dull rumble?

Just a thought.

And no, aside from testing, I won't be using the beta site, nor will I attempt to read through the discussions with that visual layout.

Comment Been there, done that... (Score 1) 145

I've done this 20 years ago. I'd be jetted around China meeting various people and introduced as a "business partner". Of course, I didn't actually do anything except smile and talk on casual subjects. Still, it was interesting and fun at the time. The benefits were good too.

I asked at one point "why", and I was told "Chinese don't trust Chinese. Chinese will trust Chinese who have Western business partners, so if you are my business partner, they'll trust me and I'll get the business".

Hard to argue with that.

Comment Re:A misunderstanding of responsible disclosure .. (Score 1) 182

Unfortunately, the vendor could take it out on the company.

"Oh, our software maintenance fees have increased by 100% (for you only)"

No, since their company was so dependent on Vendors software, they couldn't realistically do that without paying the consequences later.

Two suggestions:

1/ find some kind of fix, then post the exploit anonymously

2/ report the bug to a third party who will then approach the vendor with a "fix in x days or else we post to the world" proposal. This way, the original party can avoid the potential backlash from Vendor

Comment Re:So I'll ask again (Score 1) 387

So, if you believe in this idea so strongly, create it yourself.

Just remember that you have to take into account little things like:
- fraud prevention
- interfacing with wildly varying ad servers with wildly different features and wildly different conventions for ad calls
- the need to pull inappropriate ads from the cached ad queue asynchronously
- proper reporting of ads actually delivered
- proper ad rotation, which will depend on ads have actually been delivered
- handling rotation limited ad deliveries
- different webserver environments (IIS, apache, yadda, yadda, yadda.)
- and many, many more...

Can most of this be done? Actually it is possible, although I suspect that the resulting adserver would be feature limited (remember, it needs to work across all kinds of different webservers) and there are some features that cannot be implemented without a central adserver to coordinate the data.) The end result might be something that is too complex for websites to actually implement.

One of the biggest barriers would be the website owners. They don't want to mess with their servers just so they can deliver ads. Contrast installing something to manage the cached delivery of ads pulled from some ad providers adserver vs doing something like adding two lines of javascript (one to load the ad delivery library and one to make an actual ad call.

It all seems simple until you actually have to implement it.

Comment Re:Needless loss (Score 1) 450

Basically, when the site crashed, he had three copies (2 RAID, 1 backup) of the data: all corrupt. The guy wasn't totally retarded when it came to backups, just 80% retarded.

No, no. He was still 100% retarded.

If you don't test your backups, it means you don't have backups.

Anyone with an ounce of sense and a modicum of experience will realize that ol' Murphy plays merry havoc with even the best of plans.

If the data is important, you have to assume everything can and will go tits up - probably all at the same time so your backup plans have to take this into account.

Slashdot Top Deals

It appears that PL/I (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- J. Sammet

Working...