This is really nice. As someone who has worked with the competition libs masonry, packery, and gridster, I know why you built this and it looks great so far. All have their oddities or missing features.
Can you sort items on this programatically? If so very cool, its one feature packery is missing.
On feature I (need) think is missing is the ability to freely place an item in the bottom-right side with gaps in between it and other items - for example in the bottom right corner of the parent container. I could really see this being requested in a dashboard type use.
Yes you can. The grid is generated left-to-right > top-to-bottom, based on a 1d index inside a list. So you can sort the unidimensional array of items however you want, and then regenerate 2d positions based on that.
> On feature I (need) think is missing is the ability to freely place an item in the bottom-right side with gaps in between it and other items
You can't right now without a few tweaks, but once we start accommodating for more options this will definitely be included. We have a certain force called "pull to left" that can be replaced with "pull to top" or just don't pull, let the items be where they are placed, etc.
This was just our use-case, waiting for others to surface and see where this can go.
So this is definitely cool, but I'm not quite seeing what the purpose or aim is.
Is the demo an accurate representation of the entire functionality?
If so, why do things "fall back" toward the left? Sometimes this jumbles the layout of other blocks quite a bit. I guess this brings me back to my original question: what's this for?
Finally, the UI component being a jquery plugin strikes me as being a downside. Though I use jquery all the time, components tend to be a little brittle when it comes to heavily dynamic sites (i.e. knockout/angular/react whatever), and given that jquery itself isn't trivial, adding lots of components to it makes me a little leery of the upgrade process (also something I've witnessed problems with).
Well we're building a platform for Social Media Monitoring, with Dashboards made of resizable, responsive and composable Widgets. This grid offers you the possibility to generate customized dashboards populated with various types of data and visualizations. We wanted dashboards to be easy to create but also accommodate various screen sizes or device types. You can have one row for phones and 6 for status monitors in the lobby. etc.
The grid actually works on a principle called "pull to left." It was a UX decision in the end. "Left" is because the grid is designed horizontally (but should be made an option to use the other axis very easily), and "pull" is because we found (after much usability testing) that if you don't have any force in a drag and drop system, items will involuntarily continue to move away from each other as you move them around and collisions occur.
I get where you come from with the jQuery plugin. However, due to many reasons (including time and reducing in-house complexity) jQuery was advantageous for its build-in drag and drop capabilities. But the good part is that we still separated most of our logic from the jQuery plugin, into abstract positioning. The jQuery plugin just transforms grid data into pixels and lays them around. There are many reasons why this is cool. 1. Very fast unit tests ran with Node, 2. Grid positions can be generated server side, etc.
I have created a responsive version of gridster using bootstrap, much like this, for the interested sould. For the interested souls: http://ncthis.github.io/gridster-bootstrap/
Gridster is the most popular and current ruler of the "market." We went back and forth quite a bit with this -- meaning that I had to convince the stakeholders twice before being able to start something in-house :)
The main reason we couldn't use gridster was because it's vertical and we wanted a horizontal grid, and that gridster is not very maintained any more (you can read their README.) There are some notable forks, including one here there was an attempt to make the grid work horizontally, but which seemed far from stable and the complexity of the grister code (I read it all) seemed to much of a hustle to contribute (think estimates, etc.) It was definitely the best decision, in the end our GridList lib ended up way lighter than gridster, and we even have a pretty slick collisions implementation (not at all by the book tho, but covering more cases)
There are more small reasons like responsiveness, resizing based on a 1d index, resizing items, etc.
We use jQuery.draggable for drag and drop, which I don't think supports touch events. But there are more ways to add touch events to jQuery UI and in the end the drag and drop / plugin part is so decoupled that it can be replaced at any time. It's also the part we invested the least in so far, we wanted to have solid grid positioning and collision management first.
This post got nailed by the voting ring detector, but I'm restoring it because we want to see original work on HN.
Please everybody, don't ring-vote your posts; just take your chances with HN's randomness. If a post is solid and hasn't gotten any attention yet, a couple of reposts is ok. Be careful not to abuse that, since we eventually penalize accounts for reposting too much. Send questions to [email protected].
So many original content posts have been nailed by the voting ring detector. I can almost guarantee that many of those "friends asking friends for votes" usually have no connection to the original author at all. Maybe it's just friends sharing things with each other... I really wonder how accurate training / testing data could be gathered for this classification task. Maybe it needs to be refreshed.
Anyway thanks for bringing original content back to HN. Anyone know if there's a demo page for this library?
I did share the HN link on Campfire and colleagues must've jumped to pitch in. It is hard to draw the line but I can see how this sort of behavior should be unrecommended from the start.
Thanks for being so transparent and for spinning this back up. Lesson learned, but I have to ask, are profiles also flagged once they are associated with posts nailed by the vote ring detector?
[+] [-] mc_hammer|12 years ago|reply
Can you sort items on this programatically? If so very cool, its one feature packery is missing.
On feature I (need) think is missing is the ability to freely place an item in the bottom-right side with gaps in between it and other items - for example in the bottom right corner of the parent container. I could really see this being requested in a dashboard type use.
[+] [-] skidding|12 years ago|reply
Yes you can. The grid is generated left-to-right > top-to-bottom, based on a 1d index inside a list. So you can sort the unidimensional array of items however you want, and then regenerate 2d positions based on that.
> On feature I (need) think is missing is the ability to freely place an item in the bottom-right side with gaps in between it and other items
You can't right now without a few tweaks, but once we start accommodating for more options this will definitely be included. We have a certain force called "pull to left" that can be replaced with "pull to top" or just don't pull, let the items be where they are placed, etc.
This was just our use-case, waiting for others to surface and see where this can go.
[+] [-] Buetol|12 years ago|reply
[+] [-] skidding|12 years ago|reply
[+] [-] emn13|12 years ago|reply
Is the demo an accurate representation of the entire functionality?
If so, why do things "fall back" toward the left? Sometimes this jumbles the layout of other blocks quite a bit. I guess this brings me back to my original question: what's this for?
Finally, the UI component being a jquery plugin strikes me as being a downside. Though I use jquery all the time, components tend to be a little brittle when it comes to heavily dynamic sites (i.e. knockout/angular/react whatever), and given that jquery itself isn't trivial, adding lots of components to it makes me a little leery of the upgrade process (also something I've witnessed problems with).
[+] [-] skidding|12 years ago|reply
The grid actually works on a principle called "pull to left." It was a UX decision in the end. "Left" is because the grid is designed horizontally (but should be made an option to use the other axis very easily), and "pull" is because we found (after much usability testing) that if you don't have any force in a drag and drop system, items will involuntarily continue to move away from each other as you move them around and collisions occur.
I get where you come from with the jQuery plugin. However, due to many reasons (including time and reducing in-house complexity) jQuery was advantageous for its build-in drag and drop capabilities. But the good part is that we still separated most of our logic from the jQuery plugin, into abstract positioning. The jQuery plugin just transforms grid data into pixels and lays them around. There are many reasons why this is cool. 1. Very fast unit tests ran with Node, 2. Grid positions can be generated server side, etc.
[+] [-] Edmond|12 years ago|reply
I would be happy to discuss :)
[+] [-] vuzum|12 years ago|reply
[+] [-] skidding|12 years ago|reply
[+] [-] lunarcave|12 years ago|reply
Demo: https://rawgithub.com/ncthis/gridster-bootstrap/master/demo/...
[+] [-] skidding|12 years ago|reply
The main reason we couldn't use gridster was because it's vertical and we wanted a horizontal grid, and that gridster is not very maintained any more (you can read their README.) There are some notable forks, including one here there was an attempt to make the grid work horizontally, but which seemed far from stable and the complexity of the grister code (I read it all) seemed to much of a hustle to contribute (think estimates, etc.) It was definitely the best decision, in the end our GridList lib ended up way lighter than gridster, and we even have a pretty slick collisions implementation (not at all by the book tho, but covering more cases)
There are more small reasons like responsiveness, resizing based on a 1d index, resizing items, etc.
[+] [-] WhitneyLand|12 years ago|reply
[+] [-] skidding|12 years ago|reply
[+] [-] jamespollack|12 years ago|reply
[+] [-] ibash|12 years ago|reply
[+] [-] dang|12 years ago|reply
Please everybody, don't ring-vote your posts; just take your chances with HN's randomness. If a post is solid and hasn't gotten any attention yet, a couple of reposts is ok. Be careful not to abuse that, since we eventually penalize accounts for reposting too much. Send questions to [email protected].
[+] [-] compare|12 years ago|reply
Anyway thanks for bringing original content back to HN. Anyone know if there's a demo page for this library?
[+] [-] MattyMc|12 years ago|reply
[+] [-] skidding|12 years ago|reply
I did share the HN link on Campfire and colleagues must've jumped to pitch in. It is hard to draw the line but I can see how this sort of behavior should be unrecommended from the start.
Thanks for being so transparent and for spinning this back up. Lesson learned, but I have to ask, are profiles also flagged once they are associated with posts nailed by the vote ring detector?