Drag 'n Drop boards

[NanoSector]

Allright.

This way of moving boards...*cough*prettysucks*cough* looks good, but

It would be nice to have support like drag and drop boards in the order you want...then hit the little Save button to save the order.

(oh and remember this is a feature requests topic...)

[Arantor]

Nice idea. Not that easy to implement cross-browser, mind, but certainly interesting to look at.

[青山 素子]

SMF's method is better than some other forum software I've tried where you have to manually number the boards. Not to say that SMF couldn't do better, however. It's a nice idea overall.

Nice idea. Not that easy to implement cross-browser, mind, but certainly interesting to look at.

jQuery might be able to help with the cross-browser stuff and I seem to recall one of the developers saying they were looking at using it in the future.

[steve in houston]

how often would you reorder your boards?
im not sure if the time and effort is worth it.

[NanoSector]

how often would you reorder your boards?
im not sure if the time and effort is worth it.

I'm sure the effort is worth it

Forum owners that just start with the SMF software can rearrange their boards easier.

@ Motoko: I know. The other forum software have lots of things which SMF does a better job in. Thanks anyway.

@ Arantor: Thanks.

[青山 素子]

how often would you reorder your boards?
im not sure if the time and effort is worth it.

I'm sure the effort is worth it

Maybe, maybe not. As user steve pointed out, changing the board order isn't a common task. If it's the same effort to implement this request and a fairly public higher-demand request, the effort might be better spent on that other request. In other words, something like this is low-visibility and low-priority in relative terms.

Forum owners that just start with the SMF software can rearrange their boards easier.

Not sure I understand that. Once converted to SMF, a forum should be able to have board order changed just as if it was running SMF from day 1.


By the way, keep in mind there are some odd cases of "drag and drop" board ordering causing odd issues. For instance, Drupal supports drag-and-drop reordering in many areas. I'm working with a customer right now on cleaning up their mess of a Drupal-based site (the original developers dropped out after 70% finished, and the production site has been running almost a year in an unfinished state). One thing I've needed to do is clean up ordering. Drupal uses a signed tinyint database column (I think, key point is the range is -128 - 128) to store ordering. When you re-order something is changes the index to fit the numbering. However, because of major re-ordering in the past, about half the items were at -128 with nowhere to go from there. I had to manually re-number the items to fix the ordering issues. Increasing the size of the range would solve that problem temporarily at the cost of database space. Basically, it's not all that easy to get an implementation that is perfectly right and won't cause problems with odd behavior.

[NanoSector]

how often would you reorder your boards?
im not sure if the time and effort is worth it.

I'm sure the effort is worth it

Maybe, maybe not. As user steve pointed out, changing the board order isn't a common task. If it's the same effort to implement this request and a fairly public higher-demand request, the effort might be better spent on that other request. In other words, something like this is low-visibility and low-priority in relative terms.

Not sure what to answer on that since I don't understand a word of it LOL

Forum owners that just start with the SMF software can rearrange their boards easier.

Not sure I understand that. Once converted to SMF, a forum should be able to have board order changed just as if it was running SMF from day 1.

I mean, like a forum owner just installed SMF, he creates a few boards, and can easily re-order them without hassles of not understanding stuff, since dragging and dropping is something everybody can do.

By the way, keep in mind there are some odd cases of "drag and drop" board ordering causing odd issues. For instance, Drupal supports drag-and-drop reordering in many areas. I'm working with a customer right now on cleaning up their mess of a Drupal-based site (the original developers dropped out after 70% finished, and the production site has been running almost a year in an unfinished state). One thing I've needed to do is clean up ordering. Drupal uses a signed tinyint database column (I think, key point is the range is -128 - 128) to store ordering. When you re-order something is changes the index to fit the numbering. However, because of major re-ordering in the past, about half the items were at -128 with nowhere to go from there. I had to manually re-number the items to fix the ordering issues. Increasing the size of the range would solve that problem temporarily at the cost of database space. Basically, it's not all that easy to get an implementation that is perfectly right and won't cause problems with odd behavior.

Look at the bright side, what it has to offer, etc.

[Mick.]

Maybe for users to arrange the boards and/or categories to their likings.  Not necessary for admins only.

[NanoSector]

Maybe for users to arrange the boards and/or categories to their likings.  Not necessary for admins only.

That is a good addition to the idea

I'd really like to have this both added.

[Arantor]

Not sure what to answer on that since I don't understand a word of it LOL

What he's saying is that it's a lot of work for something that only the admin sees, and only sees infrequently, whereas there are many more things that could be done instead as better use for the time spent.

I'd really like to have this both added.

It's a cute idea, to be sure, but it raises two problems.

Firstly, performance; SMF by default uses a quirk of MySQL to keep the board index lean (and fast) since it's not just the board index that's affected, but every instance of the message index as well, and having to trawl through ordering on a per-user basis will be slower than using the normal table, not to mention eating up the DB space.

Secondly, how many boards do you have and how often do you actually rearrange them? How often would your users? I gotta say, I've never wanted to rearrange the order of boards (though I did want to collapse a category that wasn't set to collapse, once) because invariably the site owner has a better idea of how the boards should be laid out than I do... (and when I'm the site owner, I arrange them logically to start with, and don't have more boards than I really need)

[JBlaze]

I'd rather have drag 'n drop profile blocks. Or even drag 'n drop ordering of PM's. But board order? Nah.

[NanoSector]

Not sure what to answer on that since I don't understand a word of it LOL

What he's saying is that it's a lot of work for something that only the admin sees, and only sees infrequently, whereas there are many more things that could be done instead as better use for the time spent.

I'd really like to have this both added.

It's a cute idea, to be sure, but it raises two problems.

Firstly, performance; SMF by default uses a quirk of MySQL to keep the board index lean (and fast) since it's not just the board index that's affected, but every instance of the message index as well, and having to trawl through ordering on a per-user basis will be slower than using the normal table, not to mention eating up the DB space.

Secondly, how many boards do you have and how often do you actually rearrange them? How often would your users? I gotta say, I've never wanted to rearrange the order of boards (though I did want to collapse a category that wasn't set to collapse, once) because invariably the site owner has a better idea of how the boards should be laid out than I do... (and when I'm the site owner, I arrange them logically to start with, and don't have more boards than I really need)

Like I said before, first look at the bright side before looking at the problems it could make
It's just an idea, it isn't sure it is implemented yet

But to come to what you said:
1. Can't we store, which boards can be moved (using the later addition)? And can't we store it in a file apart from the database, for example? (Yeah PHP & mySQL noobie talking )

2. The users might like to have their current favorite board on top. Opinions change, you know

@ JBlaze: We could as well do Drag 'n Drop everything.

[Mick.]

Even using a JavaScript to move the cat tables up and down? Making to not make any changes or perhaps the use of cache? 


Lol, I think I'm talking way out of my league. Ha!

[Adish - (F.L.A.M.E.R)]

Like BBC's home page! That would be sooo nice...

[Suki]

Sinan made drag and drop blocks for simpleportal, per user level, that was an awesome idea, but I'm not so sure about boards, since boards aren't updated that many times,  for me drag and drop will only be efficient if and only if they really need to get update fairly often.

[Arantor]

Like I said before, first look at the bright side before looking at the problems it could make

Part of my job as a programmer is to anticipate headaches during *design* rather than try fixing them during implementation...

1. Can't we store, which boards can be moved (using the later addition)? And can't we store it in a file apart from the database, for example? (Yeah PHP & mySQL noobie talking )

Storing in a file other than the database means using the cache. Depending on what you're doing, it may be counterproductive to keep it out the database. But consider: if you don't put in the DB, you have to put it somewhere and wherever you put it, it's potentially a big setting for every single user... it's not like it's something that's low in size.

Per user cache isn't that smart as I found out during SimpleDesk's development, but for that there was no other way.

2. The users might like to have their current favorite board on top. Opinions change, you know

Then something like http://custom.simplemachines.org/mods/index.php?mod=2163 would be more suitable. I found it quite good on the site I originally made it for.

@ JBlaze: We could as well do Drag 'n Drop everything.

Then you've got to store it somewhere. Not to mention that it would make the entire page slower to load.

Even using a JavaScript to move the cat tables up and down? Making to not make any changes or perhaps the use of cache? 

Well, using the cache doesn't really help because you still have to be able to rebuild it periodically from the DB which means it's only ever good for the purpose for which it was designed: a temporary transient layer between DB and not.

As food for thought, though, on capable browsers (i.e., NOT IE prior to IE9) you could store it in localStorage and use that to rearrange it on the user's side rather than depending on the server doing it... then you have no server side storage issues whatsoever. But it carries a browser requirement.

[NanoSector]

Like I said before, first look at the bright side before looking at the problems it could make

Part of my job as a programmer is to anticipate headaches during *design* rather than try fixing them during implementation...

I've always learnt you must fix issues as you encounter them rather then fix issues as you start.

1. Can't we store, which boards can be moved (using the later addition)? And can't we store it in a file apart from the database, for example? (Yeah PHP & mySQL noobie talking )

Storing in a file other than the database means using the cache. Depending on what you're doing, it may be counterproductive to keep it out the database. But consider: if you don't put in the DB, you have to put it somewhere and wherever you put it, it's potentially a big setting for every single user... it's not like it's something that's low in size.

Per user cache isn't that smart as I found out during SimpleDesk's development, but for that there was no other way.

I didn't mean using the cache I meant something like storing it in the Themes folder.

2. The users might like to have their current favorite board on top. Opinions change, you know

Then something like http://custom.simplemachines.org/mods/index.php?mod=2163 would be more suitable. I found it quite good on the site I originally made it for.

I don't really like that mod. Drag'n'drop is better in my opinion.

@ JBlaze: We could as well do Drag 'n Drop everything.

Then you've got to store it somewhere. Not to mention that it would make the entire page slower to load.

I was just joking on that part.

[青山 素子]

Like I said before, first look at the bright side before looking at the problems it could make

Part of my job as a programmer is to anticipate headaches during *design* rather than try fixing them during implementation...\

Programmers are just code monkeys. What you're doing is the job of a software architect, which is arguably a better job...

Regardless, agreed on finding potential issues during design. It's much easier (and cheaper!) to find and correct them at that stage than later on when you have to throw out development hours or else kludge around the poor design work.

A software project should rightly be 80-90% planning and designing (architecting) and only 10% writing code. If you do the plan right, you'll have a much easier time coding and much cleaner and more maintainable code.

As food for thought, though, on capable browsers (i.e., NOT IE prior to IE9) you could store it in localStorage and use that to rearrange it on the user's side rather than depending on the server doing it... then you have no server side storage issues whatsoever. But it carries a browser requirement.

It also has a portability issue as it's stored local to the machine where you're using the browser. Switching machines would then lose the settings. Of course, you could store on the server and push to local storage if the client doesn't have the data. Of course, you'd need to find a way to store these preferences and handle that logic...

Like I said before, first look at the bright side before looking at the problems it could make

Part of my job as a programmer is to anticipate headaches during *design* rather than try fixing them during implementation...

I've always learnt you must fix issues as you encounter them rather then fix issues as you start.

Please see my first comment. Starting with a poor design leads to poor, inefficient software. The kind of stuff you read about on The Daily WTF and Coding Horrors. Proper planning including designing efficient mechanisms is crucial when you code software that will be used by thousands to millions of people daily.

[Arantor]

I've always learnt you must fix issues as you encounter them rather then fix issues as you start.

A decade of engineering experience disagrees... I guarantee it, if you spend time trying to fix problems during implementation, you will end up with a mess. This is why you sit down and *design* its structure first, and anticipate the major problems up front.

Sure, you won't anticipate everything, and you can fix the smaller stuff when you get there. I do that a fair bit, I come across something I didn't expect, and deal with it when I get there, but the really major hurdles I should anticipate and plan around them. The project manager's saying: "Failure to plan, is planning to fail."

A classic example, my drafts mod does what struck me as security in the original implementation: attempting to delete a draft requires that it looks up against the topic. But if the topic's been merged or deleted, that's no longer possible, so the draft can't be deleted either. This is a design flaw I should have anticipated and didn't. Fixing it isn't as simple as unwinding the topic from the delete check, and so when I reimplemented it much more thoroughly, I included that in my design because it required restructuring all the code to do it properly.

But many of the issues I did encounter in the reimplementation I knew of ahead of even writing the first line of code because I designed it to account for all the odd things I'd seen in the original implementation. Just patching the code would have given me a very ugly patchwork solution.

Motoko actually gets at exactly what I'm talking about, though as ever far more elegantly than I usually manage to explain it.

I didn't mean using the cache  I meant something like storing it in the Themes folder.

So you want to create a second system to replace the two already quite optimised components, never mind all the issues with respect to file permissions... and it doesn't solve the problem, merely relocates it.

I don't really like that mod. Drag'n'drop is better in my opinion.

And the fact I wrote it originally has *nothing* to do with it, of course.

I was just joking on that part.

I wasn't. There is value to allowing users to drag and drop everything (or virtually everything) on the page, as indicated earlier with SimplePortal offering the ability for users to drag and drop portal blocks. But there are technical constraints against it.

It also has a portability issue as it's stored local to the machine where you're using the browser. Switching machines would then lose the settings. Of course, you could store on the server and push to local storage if the client doesn't have the data. Of course, you'd need to find a way to store these preferences and handle that logic...

Oh, I already explored all these issues myself. I just threw it out there as a possible idea... I'm not going to spend time delving into all the pros and cons, just offering it up for people to mull over.

[Joshua Dickerson]

With jQuery/HTML 5/store.js this would be pretty simple.

https://github.com/marcuswestin/store.js#readme <-- browser independent localStorage