Re-engineering & Improving Home Box (Exportables, Performance, Features, etc)

mikesteff,

I'm currently looking for a suitable Drupal-solution to build an easy, yet feature-rich dashboard.
It seems to me that right now homebox is the only reasonable point to start. Would have loved to go with D7 or Dashboard.module (Issue #786058: Using Dashboard) but booth don't seem suitable.

So: reads like you've done a really amazing job so far. I'd love to test your code and maybe help out with some issues.

One key requirement for me is getting non-Drupal widgets into the dashboard, i.e. any kind of interface for integration with Google Gadgets.

cheers,
Morgenstern

Hi mike,

custom widgets actually are a very urgent need for my use case. I want users to be able to add their own widgets through a very easy interface. I'm currently thinking about sth. like an app store or firefox-addon library thing. I'm not sure if drupal blocks are able to handle this.

Morgenstern

I've actually just released an overview of dashboard modules in Drupal (a presentation I gave a couple of days ago) at
http://www.blog.helgemorgenstern.de/en/2010/may/state-drupal-dashboards

Looks like we're having quite similar thoughts on both dashboard and homebox. My conclusion was that homebox is rather uncertain for the future with dashboard coming up and dashboard likewise isn't complete / stable / available enough to reach current requirements.

add to that:
which code from dashboard module did you have a look at? The one from CVS? that seemed quite outdated to me, although the last time I had a look at it was some days ago. I'd really like to get a closer look at dashboard's current code, especially to get to know how they integrate external widgets.

plus: I really understand and honor your recent attempts in improving homebox. it's a pitty that homebox and dashboard don't work together (in my opinion they should: dashboard = homebox 2.0!) - but sometimes you just cannot wait weeks/month for sth. being completely finished when you need it urgently (same with me right now).

hehe oh yeah ... it was rather hard to actually write down "where drupal sucks" but compared to another alternative (the companies own java/posgresql dashboard approach which works just fine with Google Gadget API) I just had to be honest about the cons of drupal, too ;) Nevertheless I'm still an advocate for Drupal due to thinks like community (this issue is the perfect example) and future development of the dashboard to maybe some day become a fully featured intranet.

I had a look at DevSeeds stuff - oh yeah and I like it a lot! Actually I also talked a lot about it after my presentation in Hannover on tuesday. But as you said, it's really complicated and I'm not sure if you can make it as damn simple and non-techie-user-friendly as need ;)

Hi Mike,

thanks for your efforts to push homebox to a new level! I would love the possibility to aggregate RSS-feeds on a per user basis (as described here).

Raphael

Getting this dashboard thing done will be part of my bachelor thesis / work nearly fulltime for the next month. There's another student who's going to work on the same topic. We're currently in the process of evaluating the companies and its employee's requirements for this and are going to decide between drupal and a custom coded java/postgresql solution during the next 2 weeks. I'd really love to go the drupal way and improve its dashboard features along the way but it's also going to be a somewhat political decision inside the company. Being able to rapidly present a nice prototype / roadmap would be a great pro for drupal though.

As i mentioned before: a key requirement is being able to aggregate data from several other sources and display this data on a per-user basis on dashboards. If we get the right people to decide for drupal we'll probably be able to do a lot of work on this topic during the next weeks.

Some more ideas for improvements:
- being able to temporarily maximize widgets
- user-defined tabs on a dashboard (dashboard module has that)

custom content per user
Do you think it might be possible to actually add nodes to homebox? I've been thinking about that for quite some time now. Just think of a custom content type 'widget' which users can add. Every widget-content authored by user ABC could then be added to any homebox of this user. Thus users would be able to actually add HTML to their dashboard which would satisfy quite a lot of use cases.

Furthermore one could use rules to add states to this content type and build a moderation workflow. This would enable user ABC to propose his widget to other users. After being reviewed by moderator DEF (rules) every other can add this widget to his homebox, too by simply enabling it from some kind of firefox-addon-library-style page.

Major problem to be solved: being able to add nodes to homebox. I'm not familiar with homebox code yet, so what's your opinion on that. Is it possible / easy to do? Where should one start.

Subscribing

'maximizing' widgets done
widgets have an additional icon which you can use to temporarily maximize a widget. The maximized widget takes the size of the whole homebox and all other widgets are hidden. By clicking the 'minimize' icon the widget is restored into it's original place inside homebox and all other widgets are visible again.

Screenshots:
http://img.skitch.com/20100516-bx83ugnfsegfth5fp4b23ut5jw.jpg
http://img.skitch.com/20100516-kn5eudwxy5wnxbsqtxjcrya4cy.jpg

Looking forward to your feedback.

maximize widgets
yeah it's actually already working.

Custom Widgets
I also tried your idea in #26 which worked just fine. Just started to work on integrating nodes into homebox. It's working since some minutes, too. Some of this stuff is still hard-coded and needs configuration options and checks for enabled modules etc. but it works with my configuration right now.
Content-Type: 'widget'
Flag Module to mark 'widget' content as 'enabled' / 'disabled' by each user
custom code in homebox.module to add 'enabled' content of type 'widget' to homeboxes

Sandbox
You can go and create an account at my Dev Sandbox
http://www.dashboard.helgemorgenstern.de and check out what I did so far.

State of dashboard.module
Also: Kieran Lal (amazon) contacted me and sent me the most recent code from dashboard.modul, which is actually the same stuff I got from CVS and which is really old (sth. around summer 2009). Probably they should just start over and use / improve homebox. They'd get a lot of things working without duplicating code and effort. Kieran invited me to join their call at 5PM EST on Wednesday. I don't know yet if I'm going to be able to take part.

I opened another issue at #800468: Maximizing portlets including my js-code and css for maximizing portlets. Icons are attached, too. I've done them. They're free to be added to and used by homebox.

Additionally
Add Content button
- should be renamed to 'manage content' or sth similar (you're also able to remove content there)
- the following css (in homebox.css) can be used to style the button the way I did it on http://www.dashboard.helgemorgenstern.de . It also styles the list of available blocks inside the settings, which makes it a bit more compact in my opinion:

#homebox-add {
  border: 1px solid #dfdfdf;
  background: #efefef;
  padding: 4px 1em;
  text-decoration: none;
  display: inline-block;
  position: absolute;
  top: 55px;
  right: 10px;
}
#homebox-settings {
  float: left;
  display: block;
  width: 100%;
}
#homebox-settings li {
  list-style: none; 
  background: transparent;
  display: inline-block;
  border: 1px solid #dfdfdf;
  padding: 2px 5px 2px 2px;
  margin: 2px;
}

And in homebox.tpl.php we definitely should change

<input type="checkbox" class="homebox_toggle_box" <?php print $block['checked'] ?> id="homebox_toggle_<?php print $block['dom_id'] ?>" /><?php print $block['subject'] ?>

to

<input type="checkbox" class="homebox_toggle_box" <?php print $block['checked'] ?> id="homebox_toggle_<?php print $block['dom_id'] ?>" /><label for="homebox_toggle_<?php print $block['dom_id'] ?>"><?php print $block['subject'] ?></label>

this makes it much easier to select/deselect blocks.

Dashboard module
Kieran actually sent me the code that is also available on CVS (which is old). Thus I still haven't seen the most recent version.

Call on wednesday
yeah, I'll probably be there, too. Just had to get my mind sorted concerning time shift (mixed up 11am and 11pm).

Sounds like I should be checking on homebox more often!! Exciting stuff coming up:)

Hi Mike and Morgen,
I am also need of similar feature/module. For time being, I made something like dashboard using views and panels with very limited functionality. I would also like to contribute in this project.
thanks

Hi all,

Seems like there's a lot of discussion going on here! Good. I was off for a few days. I need to read all my emails, do the urgent stuff, etc. I'll would be glad to have help, open CSV accounts, etc.

I just need some time be back!
Jérémy

Hi mikestefff,

You appear to not have a Drupal CVS account. For now I'm unable to grant you access the CVS repo. Tell me as soon as you have one. (http://drupal.org/cvs-application)

Morgenstern, do you want a CVS account too?

Let me known guys.
Jérémy

Applying for a CVS account has been on my todo list since quite a while now. I just don't have anything 'complete' enough to submit for review along with my application. Don't know if improvements to an existing module count for review. I'll probably build sth. during the next days, submit my application and hopefully get an account soon.

I like the way this module is going. I'm using in it on a new project and these options sound great. Really like the re-engineering part. Also it seems better to fix this module in stead of waiting for dashboard, definitely after reading your comment mikestefff.

Since there is working getting done may i suggest a option that would be easier to implement then adding own content but could be quite handy for admins. It's a option for admins to disable the closing of a box. We now can disable the dragging but they still can be closed. Would be nice to have a option to stop dragging and stop closing.

Anyway thanks for putting in all the work in this module and i will be following.

Hi all,

I've just taken some time to read the thread.

First things first

I'm really happy to see some contribution for this module as I'm not able to give it enough time to be super active. So, Thanks you all, thank you mikestefff!

CVS accounts

I really think that CVS application is an easy step, because (co)-maintaining a module is something unvaluable for the community. I think a simple link to this thread in your application proposal would do it great!

Current state & future direction

When I did this module my first goals were:

• as few dependencies as possible (jQuery UI was already a nightmare for most users to set up, so avoid complexity)
• give a common and understandable block / box / whatever generation mechanism (block are great in this approach with Views and Panels, along with Ajax options), but it's clearly not enough today
• and of course if you look back in time before the first stable release, as Homebox was a feature requested by a client of mine, I needed something that just worked and that was maintainable. This was hard to find in this period.

Of course there is always the question of duplicating effort. As you all mentioned, and from the slides I've seen in a post earlier, you know there is Dashboard contrib module, but also D7 core Dashboard module, but we can also count on Boxes (http://drupal.org/project/boxes) from DevSeed guys (implemented in Open Atrium and Managing News I think). This one isn't really serving the same purpose, but it's definitely something to look at.

What is releasing mikestefff is great I think, because this responds to long time (shame on me) user requests, but it also makes homebox (from what I've seen so far) more Drupalistic for a 2010 module. I.E. exportables, scalable, featurable, contextable, etc. This is great value.

Few weeks ago I tried to re-think homebox from bottom to top. And made some test code, this is not something that is fully working, but an approach I wanted to test. I just opened a github repo so that you can look at the code: http://github.com/jchatard/homebox

My attempt was:

• allow non core-block things to create "homebox widget/box"
• keep those things definition in code
• let other module declare that they implement/provide boxes (simple hook)
• load boxes through Ajax calls on page load (CTools)
• handle multiple tabs on the fly (Ajax loaded)
• construct each box with a set of optionable regions (title, settings, content, header, footer, etc.)
• Objected Oriented approach for "homebox pages", "homebox tabs" and "homebox boxes" with some pretty sane default implementation which could let other module developpers provide new things (pages, tabs, boxes) from as few code as possible, so that they don't have to handle/worry about homebox behaviours or bug or API changes.

My conclusion to this attempt is fairly simple:

• not enough time to work on this for now
• could be a good idea, but there is a clear choice to make between flexibility (from the developer approach, think API, etc.) and what really users want: features. And the balance was hard to determine for me, at least.

Jérémy

Mikestefff: Great thanks!

Mikestefff: When we look at google i think we can learn a lot about good UX. Clicking a header to drag it does nothing with the box. Maybe we could give it some margin when you grab a block, like at igoogle. Also i think we could send the block faster to its new position, it is kind of slow at the moment.

Hi!

is it possible to allow homeboxes to be added to the static sidebar (at the right)? It would be cool if users could arrange the content of the sidebar, currently we use normal drupal blocks, but they are very limited in that way.

Raphael

Just found out about yet another dashboard project through a comment on my slides @slideshare 'State of Drupal Dashboards' (http://www.slideshare.net/mrgnstrn/state-of-drupal-dashboards)
Code is available on: http://github.com/kristofvanroy/nice-dash
They actually don't have drag'n'drop etc. but just for the sake of completeness. Told them about homebox and whats going on here.

@mikesteff I'm still not able to reproduce the bug you described. Tested it on Mac/Chrome, Mac/FF, Mac/Safari, Win/FF, Win/Chrome - hard to debug this without being able to reproduce it :(

@mikesteff Thx. Do you maintain an internal request tracker or what would be a nice way to track new requests? This thread may become difficult to maintain with more and more comments. Maybe I should open new issues for new requests?

Raphael

I tested the bug on Ubuntu 10.04 with FF and wasn't able to reproduce it there, too.
Let's discuss this at #800468: Maximizing portlets
Anyone else who can reproduce the bug? Instructions at the link above.
Bug reproduced and solved.

@mikestefff : granted!

Personnaly I don't see why you couldn't, and I think translation and documentation can be improved / corrected by many people.

So having it committed lets people submit patches!

I would say go with that!

Jérémy

@mikesteff,

Thank you for taking up the re-engineering of homebox.
I made a few enhancements to homebox for my current project. Attached is a patch with what I have so far.

1) Added the ability to display multiple homebox pages in a tabbed format (homebox/tabs).
Regular users can add homebox pages/tabs. A new permission 'create homebox pages' has been added
and users with this permission can create new pages. User created pages can be viewable only by the user.
A new system level homebox page is created (pid = -1) and admins can assign blocks to this page.
Users can use the blocks assigned to his system level homebox page to customize their newly added page.
To provide scalability, I have moved all the page settings for number of columns, caching, colors
from being stored in variables to homebox_pages table.
I have not deleted/cleaned up the variables that had been created, so that you can rollback easily.

2)
Added a new setting on homebox layout pages to indicate whether a given block is deletable.
Users will not have the ability to remove/close this block from their page.

3)
Addressed http://drupal.org/node/797930
Fixed AJAX callbacks so that returned blocks are a part of the users page.

4)
Added a new text area in admin/build/homebox/edit
where PHP code can be added to further limit the display of homebox pages.
TO view a homebox, a user needs to have both "access homebox " permission and the PHP code needs to evaluate to TRUE

TODO:
1) Users cannot change the number of columns in their homebox page Or delete their homebox page.
2) When displaying homebox in tabbed format, provide the ability for users to set a default tab
3) Customize CSS.
4) Use nodes in addition to blocks - I plan on using what you have.
5) Ability to Override block titles

INTRUCTIONS to use patch:
1) Apply the attached patch file
2) run update.php (update hook 6006)

Mikestefff: thanks for adding that, and the dubble click rocks!

This seems to become great stuff..is it a sort of ctools/panels, but then userbased?
subscribing, greetings, Martijn

@mikestefff

1) The "special" homebox page with pid -1( or any other pid configurable using a variable), is created and configured by the admin only to list all the blocks that regular users can add to their pages. When a user (not admin) adds a new homebox page/tab using AJAX (not using admin/build/homebox), only the blocks listed in this "special" page are made available for the user to add to his/her homebox. This AJAX function creates an entry in homebox_pages for that user, queries all the blocks in homebox_default for the "special" page and saves them in homebox_users associated with the newly created pid. When a users homebox pages are displayed, both admin created homebox pages that the user has permission to view and user created homebox pages are displayed in a tabbed format.

3) I added validation only during the AJAX saves as it was missing there, not during merge.

4) This is very similar to the block system, where the block is displayed based drupal role and/or when a certain bit of php code evaluates to true. There are so many classes of users in my current project that using only drupal roles don't suffice. People who need it can use it, the rest can work with drupal roles.

Thanks again! I am waiting to test what you have.

Hi all!

I'm a bit late (as usual) but my free time doesn't let me do more for the moment.

I've re-read the topic, downloaded and tested (just a few minutes) the current DEV release. I have to say I'm very happy to see the module evolve that way. So once again many thanks to all contributors and espacially @mikestefff the new committer and co-maintainer which really does I huge amount of work! Really thank you.

For I've seen so far (and I didn't checked every line code changes) I've only 2 negative things to report (they not huge don't worry ;-).

1. I wouldn't say that the 2.x-DEV branch is production ready because it is not, actually. As you say mikestefff the 2 branch needs to debugged a lot. When I first released Home box I spent almost an entire week to test every situation (permissions respect, views integration, etc.), every browser, any kind of stuff to be sure it as stable as possible, and I think this way the module just had few fix release for more than a year. The fact that there is no upgrade path is one big deal that production sites can handle, but if the second branch contains annoying bugs that would lead them to think that making the switch was a big mistake. So I would really wait a really stable version (in green, ahah) to say that the module is production ready. (I changed the text from the project description page for the mean time).

2. The second point is about the way an homebox page saves the user changes. As you mentioned (@mikestefff), you turned off the autosave 'sort of' feature, and replaced it with a "Button" (sort of, too). I don't really care if I need to click or not. But the fact is first branch users are used to the previous behaviour, and I don't remember that a single user complained about it. The new system implies that the user knows/remember that she needs to actually make an action to save her changes. From a usability perspective I don't find this great. My clients currently using the module mostly for backend purposes have home boxes pages which scrolls, and scrolls for sometimes 3 or 4 screen heights. If they need to go to the top to save this is a waste of time compared to the previous version and lead them to lost all the custmozation they just made. Really this is my opinion, and if I'm the only one that cares about 'autosave' on change, just let it go! Maybe we should ask users on this point.

By the way as I've said, I love the work that is being done, and I appreciate all efforts you make to improve the module, thanks!

Jérémy

Me again,

The module is really not production ready as Views exposed filters are no longer working.

The behaviour is this one:

1. Create a view with a block display
2. In this display active one or more exposed filters
3. Set the display settings to use Ajax (YES), and 'Exposed form in block' must be set to YES also.

The exposed filters should appear on the home box header (click the wheel) to let user filter her View. This is explained in the first branch advanced help documentation.

Jérémy

Yes I really think the upgrade path is something that most sites can handle by hand, I'm not worry about that.

You are right for the autosave behaviour. In your current implemenation would it be difficult to set this as an option per pages for example?

@82
Maybe I didn't get the last version as in the one I've installed the is no separate module for OG. Maybe this is it!

@86 Ok just test without 'Expose filter in block' and it works fine.

In first branch, when 'Expose filter in block' was set to ON, the exposed filters used to appear in hidden zone (as colors) this why I set it on to test.

So i'm testing this module and the first thing i came across is:
- Fresh install home box v2
- Add new page
- Set permission for authenticated user (or any other role)
- Save it
- Click edit in the overview of home box pages
- No role is selected

- In the overview of home box pages
- Click Settings of a page
- Press save button
- You are redirected to the settings page instead of the overview page

**deleted

i keep getting a 404.
- Administer home box is set for authenticated users
- Enable the Page is set
- Home box has blocks in it

Some comments on usability:
- We should have a hint like "You have made changes to this page. Use 'Save settings' to save them."
- unmovable and unclosable widgets should be themed in a different way so users are able to actually see that those widgets can not be moved or closed.
- users should get some kind of feedback after clicking "Restore to defaults" and "Save settings".
- use html <label> for checkboxes and their labels at "Edit content" (see comment #34 http://drupal.org/node/794728#comment-2974128)

I'll start working on those today.

@mikesteff

The labels make it so you can click the text as well as the checkbox, right? If so, then I like it and will add it.

Yep! :)

@101 and 102: I agree that the current way to have a long list of checkboxes isn't very user friendly. However I'd rather argue against a popUp dialog solution. The guys from dashboard module eg. try to avoid dialogs and popups for a reason. I think it would be much better to have a separat page that functions similar to Firefox Addons (not that overloaded though) https://addons.mozilla.org just to enable (=install) widgets for your dashboard. This would be great in combination with description for widgets + tags and views I think. Everything else like customization of widgets (color etc), moving, minimizing and also closing widgets can be accessed right through the dashboard / homebox screen (probably hide those icons and just show them on .portlet:hover?).

@103 Oh my ... thats AWESOME! Should be documented by a hint right next to these settings, though.

mikestefff: your going fast, love the speed! I'm still trying to fix the 404 problem, when this is done i will continue the testing.

i;m working on this right now. i will uninstall the 2.0 version, install 1.0 en reinstall it again and then download the new 2.0. Ill get back soon.

New issue: home box is spelled with a 'dash'-home box. In the user rights it is spelled without a dash. So searching (ctrl+f) for home box returns no result.

This still excists:
- In the overview of home box pages
- Click Settings of a page
- Press save button
- You are redirected to the settings page instead of the overview page

404 error was because in my aliases i had it still there from the homebox v1.0 version, so /dashboard was still refering to homebox/1. 404 is fixed. Going to test the rest.

first impressions: i love the speed of placing the blocks and love the tooltips!

print homebox_build('dashboard');
returns : This page has not yet been configured.
Machine name is : dashboard

- 111: i mean: role rights. Where you set all the rights for a role.

- popup dialogs suck at my side, the theming of them is not working, do i have to download manually the jqueryui css?

Why i want to use the homebox_build is for the following reason. When someone is loged-in they are taken to the front page. And the frontpage i want for loged-in users to be the home box. So when they click the home button the home box is the loged-in users home.

  <?php if( user_is_logged_in() && $is_front ): ?>
    <?php if( $user_nav ): ?>
      <?php print $user_nav; ?>
    <?php endif; ?>
    <div class="row">
      <?php print homebox_build('dashboard'); ?>
    </div>
  <?php else: ?>
  print content things.

i basically don't use the menu entry nor the dashboard path. I just want the frontpage for loged-in users to be the dashboard. I use it in page.tpl.php.

when you press save settings without doing anything. the popup keeps saying saving settings and does not disappear.

- can i remove the close and show effect on a block? This gives me problems with my main container.
- the toggle link / popup seems not correct, it is now not any more a toggle because we can only use it to activate hidden content. i +1 for having the option to use the checkboxes also to close a block.

@121 : print homebox_build(homebox_get_page('dashboard')); works, i manually have to call for the js's but that was in v1 also.

@121: jqury ui is 6.x-1.3

@111 : no i mean the drupal core function for role permissions.

The following also still occurs:
- Add new page
- Set permission for authenticated user (or any other role)
- Save it
- Click edit for the created home box page in the overview of home box pages
- No role is selected

@122: what the heck your right, the checkbox was disabled but now it works, i have no idea how this happend.

i am using/testing this in a 70% developed project and do not have the time to try it on a clean install. But above seems right, must be leftovers. i have uninstalled v1 but it seems the uninstall function does not do a complete job.

using the effect for opening and closing does not stretch the opend div with class homebox-column to the height it should have and this gives problems with themeing...

jquery.ui issue:
homebox.module calls:
drupal_add_css($path = drupal_get_path('module', 'jquery_ui') .'/jquery.ui/themes/default/ui.all.css', $type = 'module', $media = 'all', $preprocess = TRUE);

But when you download the jquery_ui package from jqueryui.com the folder is not default but base.

mikestefff: maybe just use a nice fadein / fadeout? Don't know if that woulde give problems.

mikestefff: that is very strange. i just tried it at http://jqueryui.com/download only thing i changed is the version to 1.8

mm when i download 1.7 and go to the development-bundle/themes/css/ i only get base and a theme i manually select.

mikesteff: i think you use jquery ui v.1.6 that uses themes default. You are right tough this is very confusing. also strange from jquery that they changed the folder name.

hehe well that is fixed ;)

probably got to do with jquery license and drupal module disclaimer. we may nog include other codes or something like that.

jep everything works now with the jquery ui 1.6... to bad tough i like nwe versions :P

Ok the save issue is still there. When you do not change anything and press the save button the save modal will not dissapear. And another issue that rises because of the button is. Why do we need the button? I woulde like to see everything automaticaly that woulde make it a whole lot easier for users.

i love the work that has gone into the v2.0 but when i close a block or maximize it, it does not automatically save and that really is a bad thing. Is that just with me or is that something new in v2, with the save button?

- Saving settings does not save and the modal window does not disappear. it has only saved once for me and does not work anymore.

Ok i understand your point, but then we should re-think this if there is a other way to get this working. maybe place a tooltip above the save button that says something like: you have changed your content save this page how it is now.

But i really do not think this should be a manual function. There is no dashboard that works that way only home box v2. Maybe add a minimize all button? because i think this is a bit to private issue the having close all blocks upon opening the page.

Another thing is that high end websites will probably have a high end server and that should not have problems with makeing all those ajax calls. It is just so much more easy and logical to auto save it. That is also why google uses auto save. We must not make users have to do much actions. And if you really really don't like it then i +1 for a option to activate or deactivate the auto save option.

mm i use PHP Version 5.2.4-2ubuntu5.10 so that shouldnt be a problem.

i press save, and wait but the saving modal does not disappear so after 30sec to 1 minute i refresh. I use firefox maybe that caches.

I close a block and press save.

block is undefined
[Break on this error] if (block.search('homebox_') != -1) {
homebox.js?3 (regel 450)

I close a block and press save.

block is undefined
[Break on this error] if (block.search('homebox_') != -1) {
homebox.js?3 (regel 450)

I think this is a bug but will not effect many. The problem i think is because i have one block in my home box. Let me place some more in there and i will come back if thats the thing.

mm nope that's not the problem i firebug returns the same error as above.

@160: damn your were right again. i found that i had a theme file hanging around, save button works now.

@161: offcourse i could use logintobogan, but then the url would change for logedin users and i just want the main url to be the page they see. Another thing is that i would have to create a new menu element 'home' for users who are logedin. This seems to me the best way to do it but if you know anoter way that i can keep the same menu and the url will stay site.com i am happy to hear it!

i like the changes in v2. everything goes quicker and that makes it look smoother. my only 'problem' are the modal windows, there's just to mutch of them. i would make the save button not call a modal but just an a loading image (not to small) in the center of the page. if the page is saved fade out the loading image show a green check image and make that fade out. don't know if that is the way to go but it would at least kill one modal window.

i'm gone test above now. except for OG, i don't use OG and have not installed it nor can i try the hook, don't know enough of php for that. The user profile tab i tried, don't really see how to use it in real life might have sound good as a concept but it dont see use for it but will test it.

Came across a thing tough. Try placing 3 or 4 boxes under each other in one col. The col div is not stretching, gives themeing problems because i have a footer beneath the #homebox.

and another thing is that when you dont not have javascript all the options show. that's ok but not the way they are shown now. Maybe just make them trough css display:none and when javascript needs them it will display them. and when you don;t have javascript it wont show them, users issue not ours, withouth javascript the visitor isnt able to use the options (create now block, toggle etc) anyway.

ah when you save the page it does stretch the col height after the safe is done.

Option to disable theme block regions so home box can go full-width
>> works, also works in the user profile tab home box.

Number of columns
>> works

Custom columns width
>> works, nice one. looks very nice in the homebox to have the center one bigger. Only thing is that when you drag the bigger box to a side col the body want to scroll horizontal, can we make the box adapt the width of the col when you hover the box over the col? just an idea.

Boxes colors customization
>> works, but additionally maybe add: not required to use 6-characters for the color code but also work with 3 like: #fff

Custom items
>> deleting a custom box does not work. opens the modal but when you click the delete button in the modal javascript returns a alert('undefined). User options tab home box has the same issue.
>> and this options seems for how it now is... a bit useless, but it's a start. maybe add:
>>> 1) Change this content, we now get a delete box link but not change it's content.
>>> 2) Give the ability to add formats? that way we could let links be automatically generated to a link and not just text as it is now.
>>> 3) a filter of some kind? that when you place a rss feed the home box module recognizes it and renders it ???
>>> do something with it because how i see it now the only use i can see is a very basic to-do thing or reminder thing.

Custom titles
>> works, nice one.

Make a box not closable
>> works

Tooltips
>> works, very nice and smooth

Disable Block Regions
>> Returns a WSOD when you call it like i do trough php print homebox_build(homebox_get_page('dashboard'));
For me that is not a big problem because i dont not show any regions in my if but for some it might give problems.

- I noticed the problem with wider regions and the blocks not stretching out. I'll certainly try to address that soon.
>> i do not understand this. here when i transfer a box from a 20% col to a 60% it does stretch in the 60%. What i addressed was a issue with the height not the width. when you place 4 or 5 block beneath each other the col does not stretch the height that all those blocks have together.

- With the custom region widths, don't forget you can do stacked layouts now too. Try creating 4 regions of widths; 100, 50, 50, 100
>> I get that i tried that and i like it. But when you do the following width : 20 60 20, now select the 60 and drag it to the right 20 you will see the horizontal scrollbar, would be nicer if the dragging box would resize when you hover over the col and that that box then automaticaly gets the width of the col you hover over.

off course it's used for embedding, don't know whats my problem today but i'm not sharp... Maybe we could add a little help text in the add content modal window? I know my users else will have no idea what to do with the custom block option.

You are correct tough embedding does not work good, i tried embedding a slideshare presentation and it does not work at all. only shows the text.

Ok this is a strange bug.

press a couple of times on the 'customize' icon of a block, like 3 or 4 times fast after each other. the block automatically collapses... Continue clicking the customize icon and it expandse, continue this etc etc it contiunes opening and closing, while we are clicking the customize icon.

173: i will make a screengrab/movie

175: Ok that's way it collapses, cant you make it so that when you click a icon in the header it does not work. I guess when you use :not in jquery that should do the trick. when i click a icon i do not expect a other action from another element to happen.

Just getting on board now. I've used spaces-dashboard/context/features to accomplish what home-box v2.x-dev now does virtually by itself. So much less setup. Amazing work mikestefff!

I will be testing this module extensively (particularly with og and features) over the next few days and reporting back.

Also, so far I have just one request and one bump:

The administrative ability (via checkbox in layout) to shut-off the maximize option for blocks - maximize is a great option but not for every block. I'm sure you've already thought of this though.

Second, I can't wait for custom widgets as that will be an uber-amazing addition.

Kudos mikestefff!

Mikestefff: here's the list

- Change work flow:
>> In the overview of home box pages
>> Click Settings of a page
>> Press save button
>> You are redirected to the settings page instead of the overview page

- This still excisits for me, you sayd you can not recreate it:
>> Add new page
>> Set permission for authenticated user (or any other role)
>> Save it
>> Click edit for the created home box page in the overview of home box pages
>> No role is selected

- remove the close and show effect on a block.
>> Gives problems with themeing. Maybe give it a fadein/out, see if that works?

- Make auto save a option for admin.

- Give user a option to minimize all blocks in one click, and open them all in one click.
>> Make that link toggle so we don't have two links. But one that says open all. And when you clicked it says Close all.

- Hide all the modal window content trough css, display:none, so that people that do not have javascript will not see it.
>> Nor will you see the content when the page builds.

- Try placing 3 or 4 boxes under each other in one col. The col div is not stretching it's height, gives theming problems because i have a footer beneath the #homebox.

- Custom columns width, make the box adapt to the width it is hover over. So a box from a 60% col, when you hover it over a 20% col it must get that width automatically without dropping the box. When you dont drop the box and hover back to the 60% it should get that width.

- Boxes colors customization, works, but additionally maybe add: not required to use 6-characters for the color code but also work with 3 like: #fff

- When you duble click a icon it the box should not collapse and expand, this action should only work when clicking on the box text/headers white space. Clicking on icon should only call icon actions.

- Make maximizing a admin option per box
>> send it by pribeh

no problem, glad i could help.

@181. Thanks for the response mikestefff. What I meant in the my feature request was an administrative ability to disable the maximize option. I would love to use home boxes but would definitely not love to give the user the ability to maximize every box because that means I have to style every box for two different layouts (minimized and maximized). From a designers/site-builders perspective this is kind of disastrous. So the request is not to allow for on/off default functionality but "disable" functionality. Does that make sense?

Ya, that's cool. Don't get me wrong, I think that maximize option is a cool feature but I don't see the practicality for the purposes of a igoole-espue home page since most blocks or elements of a page are designed/built for certain dimensions. I love giving the user control in various contexts but sometimes too much control destroys layouts and can allow for unusable/ugly side-effects particularly when menus, static images, widgets and other items are involved.

I haven't looked at your code yet and understand if this might be difficult to code.

Also, my first bug report - using jquery ui 1.6 and latest home-box dev as of this date:

Disabling collapsible option via the layout checkbox (for a box) does not seem to work. Both authenticated and administrative users can still collapse blocks which are set to not allow said functionality.

Best,

Thomas

Hi, Would with homebox it also be possible to build more than one homebox per user?
Great development..
greetings, Martijn

Will jump on the testwagen if a alpha version is there, ok?
greetings,
Martijn

Hey mikestefff,

I've been gathering some user feedback on a test site. The one consensus seems to be that the users would like to see a static state - ala spaces_dashboard. So, instead of the igoogle-esque permanently movable boxes these users would prefer to be able to:

- user hits a button (say "customize dashboard") to activate adjustable boxes.
- (jquery loads?) user can then move boxes around.
- user hits "save"
- boxes become static.

So I'm not sure how this would be done since I've looked at the code and can't figure it out myself. I also realize that no one else here may want the module to work as such. I'm simply reporting that from a usability standpoint my test group and I would prefer a static page (so to speak) that then can then be modified temporarily - again like spaces-dashboard works).

- This avoids users accidentally clicking on boxes and shifting them around as they are clicking on links.
- Having a static page fosters a sense of stability and permanence that helps focus users attention on the real important task at hand, navigation; so users are not distracted by reorienting their page every few seconds.

I'd love to see this happen at some point but if not that's fine as I totally appreciate where the module is at, how it works currently, and the tremendous progress made so far.

Best,

Thomas

Ya, that's totally cool Mikestefff. I would disagree as to what may confuse users and admins but I'm happy to leave it at that. Thanks so much for your contributions.

that most be the dumbest thing i have heard. how can someone accidentally move a box to a other position. impossible. you have some strange users.

Ya, I know it may sound funny but the users report that the home box page "feels unstable" to them. Perhaps it's because of the context or design of the website in which it is being tested. I have to consider how to improve those to reflect stability now. Like I said, they would rather a clickable on/off button to turn on and off the movable state of the boxes. User "experience" and "feelings" are important in my testing as I build sites for thousands of users - the use-case for something like home-box. Sometimes, the wrong feeling or impression is enough to loose a few thousand users :(

mikestefff: how's it going?

in my opinion we can drop the user-added blocks - for now - and finis the last tweaks so we can get the 2.x in live. Then we can finish up the custom blocks ad release a 2.1.

I haven't been testing anymore i think everything that could be tested has been tested.

I understand. And no problem, i think we all now how that is - adding new/thinking of new futures every day -.

Hi mikesteff,

I think there is a bug related to the "Path" field.

While adding a homebox page I provided Machine name, Title & Path.

Even if I provide a path which already exists in my site, it takes that.(overrides, infact) . I expect to see an error like "The path is already in use."

I am able to use the same path for all the 3 homebox pages!! It does not throw any error. It keeps overriding and shows latest overridden homebox page on that url.

Even it accepts the sensitive paths like "admin/build/modules" !! Hence on this page admin/build/modules I see my homebox page now.

It's not checking for unique path.

~ Ipsita

Hi mikestefff,

I fixed this issue.

Attaching the patch file with this message.

The problem was because of using same variable name $path twice.

Thanks & Regards,
Ipsita

Really appreciating you to take us with you in your process! Great progress!
greetings, Martijn

Amazing work mikestefff. I'm going to do some testing today.

mikestefff: amazing stuff, the small errors are always the hardest to find. Spreading the word will be easy with this great module!

Small issue:
- Create a home box
- In the home box overview, press edit on the newly created home box
- Press save
- You get a error because the path already exists

I guess this has to do with the patch for the path's.

how is the auto-save option going and the problem with the cols not getting longer?

mikestefff: could you place a extra div around the custom blocks content? When there is a extra div we can do .custom-content *{width:100%;} i don;t know if this is a good idea. But the thing is that when someone ads content that is bigger then the box it will be automatically scaled. Offcourse we can create the css ourself but it would help if there is a div around custom content.

sure, just a class will do.

Hi mikestefff,

I have one bug to report. I've managed to successfully save the Flickr "make-a-badge" html into a custom block. The block displays just fine but as soon as I try to move the block the page is reloaded with only the contents "body" and the flickr html inside of it.

@221 attempting to move a custom block (loaded with http://www.flickr.com/badge.gne) reloads the page with no other html other than the body tag and the html contents of the custom block. I can give you an account on the development site I'm testing homebox with if you'd like. I've also attached a screen shot to illustrate.

Also, a question: are homebox custom boxes using the default input filter or full html?

Forgotten attachment :)

#222: well this should be in an individual block wrapped around the content.

mikestefff: i still get the error with the path. I uninstalled the v2, today (11:30) downloaded the new v2 and installed that. The following happens. If you edit a home box page and try to save the settings - without editing the path - you get a error that the path already is in use.

So
- click edit for a home box page
- without editing anything scroll down and save the home box page
- you get a error that the path is already in use

PS; i like the option to clear users home box settings.

- equal height of columns still is not working
- double clicking a icon still opens and closes a box

#231: move all your boxes to one column, the column height is not changed. Because of this we get problems with theming, for example when you use a footer. So the heights are equal but they do not stretch in height when you move a box in them.

Attached screenshots.

hb-1: shows the height cuts off the box, because the column height is not high enough.
hb-2: firebug shows the height which is not enough.
hb-3: home box alters height to how it should be but only after the page is saved. Firebug shows that the column has the wright height after save.

i am trying to fix the double click but it seems .not() does not work because we DO click the portlet-header even when we click the porlet-icon. Because the icons are IN the portlet-header

maybe we could place the icon outside of portlet-header. Then you could also not move them trough clicking an icon. If we place the icons beneath the potlet-header in a porlet-icons div. Make that div float right and give it a higher z-index then the portlet-header then we will not be clicking the portlet-header when we click an portlet-icon.

mikestefff: this is in my opinion a good way to fix the dbleclick().

homebox.css - add:

.portlet-title{
	width:100%;
	display:block;
}

homebox.js - change line 73 to:
$boxes.find('.portlet-title').dblclick(function() {

column height problem in garland. I think you should use higher boxes and retry.

the height gets fixed when you do a action with a box, like click a portlet-icon, maximize or minimze a box or save the page. But when you only drag a box to a column the height of that column does not change.

thats strange, screens shows what i get when i place a lot of boxes in one column.

mikestefff: this has got to do with the fact that homebox.js does not count up the new placed box(es). I see it in firebug. The element (homebox-column) has a height that is not correct. When i save the page the height gets changed to the right height.

damn, just installed everything clean and it works... have you any idea how this could be happening?

would it be posible to stretch the column height when we hover over a column with a block.

Ok this error has to do with jquery update 6.x-2.x-dev, which is shipped with jQuery JavaScript Library v1.3.2. So i guess there is a conflict with jquery ui 1.6 and jquery v1.3.2. And that offcourse sucks.

well sure, but there are modules out there which just require jquery update... I'm happy i am not using them - at the moment -. And there are jquery plugins which also require 1.3.2. So i really think we should look at the future and just make jquery update required and work with a newer jquery_ui version.

@251: i mean when we hover with a block over a column.

@256: owyeah thats it! and dude, we knew you were good about 200 posts ago ;-)

and now all we need to do is have a option to auto save or manual save. Think this would be nicely placed per create / edit homebox page.

these are the last things i can suggest / think off.

- Make jquery update required, this way we can use a newer jquery ui and go for the future.
- Make per home box page auto or manual save a option for the admin to set.
- And offcourse the list at http://drupal.org/node/794728#comment-3044644, tough mostly of that is fixed.

If those are fixed / implemented we should go live!

Hi,

I don't want to sound rude or rushing, but I'm following this module for some time now and I see that new features has been added on the fly which will impact somehow the stability, performance and will delay the release of new version.

I think that the initial idea of the module is already implemented and the dev version of Homebox is already more than feature rich. What I really need (and I'm quite sure I'm not the only one) is a stable official version of the module. I really appreciate the efforts on new features, but please concentrate on

TO-DO:
* Improved caching
* Clean up code
* Update documentation

and add new features in the next version. About jquery, jquery_update breaks a lot of contrib modules, just look at their issue queue. Please stick to core.

I'm willing to use Homebox on two high profile sites I'm working on, but I'll certainly not use a dev version. You all did some great work, let's see it in production pleeeeease :) .

Well the initial idea is indeed implemented, and with that came the manual save option. That is why the only feature remaining is the manual / auto save option. Second thing is that there are still small bugs that need to be cleaned out.

Furthermore we all want a stable version but this still is opensource and mikestefff is doing all this work, basically for nothing. In my opinion the only things really necessary are in post #260 and what you mentioned:
* Improved caching
* Clean up code

The documentation is not a big thing.

Then the jquery_update thing. Things always have pro's and con's and in my opinion the pro's for jquery_update weigh higher than the con's.

Ya, the jquery_update issue is a tough one. I can see why many would like to consider leaving it out due to compatibility issues. However, that said, Drupal 6's jquery is now years old and letting Drupal interface design fall behind the pack. I would of argued not to use jquery_update a year ago or even several months ago but now I'd argue that we really should try to push the Drupal community forward. Jquery is too important an asset and with Drupal 7 almost here most modules utilizing jquery will be updating to a more recent version of jquery for a D7 release anyway.

Hey, is anyone else experiencing what I describe in #225? Iasac?

mikestefff: well sound ok, but i still think the autosave option should be in there. specially because the module is initially based on a autosave. Second thing is the usability, i wouldn't like to always press save when i move a box.

here we have it... i'm using a modalwindow that requires jquery 1.3.2.

I've been absent for a while now as my company decided to use their own non-Drupal solution (they needed configurable Google Gadgets). However, I just installed the newest version of homebox and I really like it a lot!!! This is absolutely awesome work, mikesteff!!

I especially like the ability to add full-html custom widgets - you can actually use that feature to add iframes inside portlets!

<iframe src="http://www.google.com"></iframe>

Adding some CSS makes this a really nice solution for users to add external content. Admins can use Full-HTML blocks to add this for every user.

#homebox .homebox-portlet iframe {
  width: 100%;
  min-height: 300px;
  border: 0;
} 
#homebox .portlet-maximized iframe {
  height: 600px;
}

By the way: If anyone ever plans to add Google Gadgets, be sure to have a look at the Apache Shindig project (Java or PHP) http://shindig.apache.org/ which has a

Gadget Rendering Server: used to render the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript.

mikestefff: i am using a jquery plugin that requires 1.3.2, it worked until i discovered that jquery_update is not compatible with homebox, so uninstalled it and now the plugin doesn't work anymore. I will have to look at homebox.js to make it work with jquery 1.3.2

well a higher version of jquery is not a hacked version... But don't bother i will change the homebox.js for own use. Any idea on the release?

mikestefff: maybe http://groups.google.com/group/jquery-ui/browse_thread/thread/6f2493ad52... ?

"force upgrades across the board"? to a higher jquery? that wouldn't suck at all :P

Mikestefff: i know you are finishing everything up but i just came across the following. As you know i use jquery update and that gave conflicts with the module. I finally found where the issue is located. It's the equalizeColumnsHeights.

Drupal.homebox.equalizeColumnsHeights = function(columns) {
  maxHeight = 0;
  $columns.each(function() {
    if ($(this).parent('.homebox-column-wrapper').attr('style') != 'width: 100%;') {
      $(this).height('auto');
      currentHeight = $(this).height();
      if (maxHeight < currentHeight) {
        maxHeight = currentHeight;
      };
    };
  }).each(function() {
    if ($(this).parent('.homebox-column-wrapper').attr('style') != 'width: 100%;') {
      $(this).height(maxHeight);
    }
  });
  
  return $columns;
};

When i change the above to

Drupal.homebox.equalizeColumnsHeights = function(columns) {
  return $columns;
};

then home box works perfectly with jquery 1.3.2 and the jquery drupal is ported with (think 1.2.x). The only thing is - as expected - that the columns are not equal and therefore the dropping of a box is harder because the columns are not the same height.

So my question is; could you maybe recode that part? i think that your fresh sight could make this module work for those who also use jquery update and for those who use the jquery ported with drupal.

I really hope you can look in to this...

** EDIT **

it doesn't seem to be equalizeColumnsHeights. The problem is that jquery does not 'see' when we drop (stop()) or hover (over()) a box in a column. And that seems to have to do with.

    // Make columns sortable
    $columns.sortable({
      items: '.homebox-portlet.homebox-draggable',
      handle: '.portlet-header',
      connectWith: $columns,
      placeholder: 'homebox-placeholder',
      forcePlaceholderSize: true,
	  over: function() {
		Drupal.homebox.equalizeColumnsHeights($columns);
	  },
      stop: function() {
        Drupal.homebox.equalizeColumnsHeights($columns);
        $('#homebox-changes-made').show();
      }
    });

When you use jquery 1.3.2 and drop a box $('#homebox-changes-made').show(); is not called just like Drupal.homebox.equalizeColumnsHeights($columns);

** EDIT **

Ok so this is the last edit. This module works perfect with jquery update (1.3.2) and jquery.ui 1.7.3.

mikestefff: i just updated post #277. This modules and homebox.js work perfectly with jquery_update 1.3.2 and jquery.ui 1.7.3. I just tested all the options, restore, personal box, save, etc etc and everything works. - in Firefox.

mikestefff: only thing is that i did not change the jquery ui 1.6 css file.

>> keeping 1.2.6 does not work, gives a lot of problems, dragging and dropping does not work.

>> ie shows lots of problems

>> i do not know any module that breaks with jquery update

I;m also on this at this moment so if you discover something please keep me updated.

i also tested jquery 1.4 and jquery ui 1.8 but that breaks alsmot everything.

ie shows problems before and after upgrading. especially the dialogs, but i think you know this already.

yes problem is definitely in ui.dialog.

actually i do, i use nyromodal, that's one of the most awesome modal windows i came across. easy ajax and easy implemented. BUT it requires jquery 1.3.2... http://nyromodal.nyrodev.com/

another thing we could do is go back to the old idea in this module. By just showing and closing called div under the buttons, with some nice theming this option is definitely not a bad one. Only 'problem' would be the custom content, that's something that just must be opened in a modal, i think.

i am gone check all your comments out and test it. just gona grab something to eat real quick

@249 - deleting that stuff makes like everything work... dragging, tooltips and icons.

ok trying following: delete ONLY the two forms for the dialog the add form and edit form. everything works. Maybe place those in a div?

this makes everything work:

  <div id="homebox-add-form">
  <form title="Add a new item" class="form-item">
    <div id="homebox-add-form-status"></div>
    <label for="title">Title</label>
    <input type="text" name="title" id="homebox-add-form-title" class="" />
    <label for="content">Content</label>
    <textarea name="content" id="homebox-add-form-content" value="" class=""></textarea>
  </form>
  </div>
  <div id="homebox-edit-form">
  <form title="Edit item" class="form-item">
    <div id="homebox-edit-form-status"></div>
    <label for="title">Title</label>
    <input type="text" name="title" id="homebox-edit-form-title" class="" />
    <label for="content">Content</label>
    <textarea name="content" id="homebox-edit-form-content" value="" class=""></textarea>
    <input type="hidden" value="" />
  </form>
  </div>

Ok above really fixes everything, i don't even get a javascript error in ie8 anymore. I don't have ie7 so i can't test that. Do you run both ie8 and ie7? if so could you share how you have done that, looking for that a long time now.

i am gone test everything now with jquery update and jquery ui 1.7

work perfectly with jquery 1.3.2 and jquery ui 1.7.3. ONLY thing is that the theme folder for jquery ui is in the new version base and in the older version default, that's the only thing.

i am gone check something out, it's a new feature.

i am gone download IE TESTER.

@307: yes i knew this, that's a very annonying bug. A lot of jquery plugins have this issue. I made a small change $columns.sortable() i added containment: '#homebox' this keeps the portlets in the #homebox div, i personally like this. I am trying to get one more thing in and that is that when you hover over a column with a box it automatically changes the width of that specific box to the width of the column it hovers over, when you not have dropped the box yet.

no, i changed mine to jquery update. i will go back to the old one.

this also works with the old jquery and ui. The change is that you can not drag the portlets across the whole page they are contained in the #homebox div. I personally think we should wrap the columns in a div, because now the containment is in the #homebox, but thats also where the buttons are so you can dragg a portlet to the buttons.

forget about this, the containment makes it crappy to place a portlet at the bottom of a column. forget about it.

yes it did work for me but it's crappy with placing a portlet at the bottom of a column. I am gone try to make the widths adapt to the column when you hover over it, WHEN i get this done (seems hard for me) then i will look at the IE7 issue.

chrome does not crash for me. But just as in IE, chrome also does not change the icon... and you are right the issues are more critical.

seems that dubbleclick does not change the icon anywhere, also not in firefox. good catch.

yes that was me and i just figured out the same thing, the fix was dbclicking on .portlet-title but in .portlet-title the icons are not located.

add this on line 5 (or else where if you think it should be placed somewhere else) in homebox.js

  $(".portlet-header").disableSelection();

that way we do not see the blue for 'selecting' the portlet-header when we dubble click it, this is for IE, chrome and Opera.

the error messages in ie tester for ie7 suck a bit, i have no idea where the error could be located - what file -.

disableSelection() does what it says, it disables selecting. Core function of most browsers is dubble clicking makes a selection. That is what happens in IE, chrome and opera. disableSelection() disables this.

Remove that line and in chrome or IE dubbleclick a portlet header a couple of times to open and close it. You will see the blue selection, as if you would select text. Now readd the $(".portlet-header").disableSelection(); and again dubbleclick th portlet header, you will not see the blue selection any more.

yeah nice little function, but i am getting frustrated at ie7

Ok mikestefff: the IE7 error has to do with the save options.

Drupal.homebox.saveBoxes = function(save) {
  var color = new String();
  var open = new Boolean();
  var block = new String();
  var name = $('#homebox').find('input:hidden.name').val();
  var blocks = {};
  
  // Show progress dialog
  $('#homebox-save-message').dialog('open');

  $columns = Drupal.homebox.equalizeColumnsHeights($columns);
  $columns.each(function(colIndex) {
    // Determine region
    var colIndex = colIndex + 1;
    $(this).find('>.homebox-portlet').each(function(boxIndex) {
      // Determine block name
      block = $(this).find('input:hidden.homebox').val();
      
      // Determine visibility
      visible = 0;
      if ($(this).is(':visible')) {
        visible = 1;
      };

      // Determine custom color, if any
      attributes = $(this).attr('class').split(' ');
      color = 'default';
      for (a in attributes) {
        if (attributes[a].substr(0, 14) == 'homebox-color-') {
          color = attributes[a].substr(14);
        }
      }
      
      // Determine state (open/closed)
      open = $(this).find(".portlet-content").is(':visible');

      // Build blocks object
      if (block.search('homebox_') != -1) {
        // If block is custom, we need more data
        blocks[block] = {
          region: colIndex,
          status: visible,
          color: color,
          open: open,
          title: $(this).find('.portlet-title').html().stripTags(),
          content: $(this).find('.portlet-content').html(),
          module: 'homebox',
          delta: block.replace('homebox_', ''),
        }
      }
      else {
        blocks[block] = {
          region: colIndex,
          status: visible,
          color: color,
          open: open
        }
      }
    });
  });
 
  // Encode JSON
  blocks = JSON.stringify(blocks);
  
  $.ajax({
    url: Drupal.settings.basePath + '?q=homebox/js/save',
    type: "POST",
    cache: "false",
    dataType: "json",
    data: {name: name, blocks: blocks},
    success: function() {
      $('#homebox-save-message').dialog('close');
      $('#homebox-changes-made').hide();
      
      if (save) {
        // If a block was passed in, save it as a
        // custom block after ajax success.
        Drupal.homebox.addItemAjax(name, save); 
      }
    },
    error: function() {
      $('#homebox-save-message').html('<span style="color:red;">Save failed. Please refresh page.</span>');
      console.log(Drupal.t("An error occured while trying to save you settings."))
    }
  });
}

Remove above frome homebox.js and the error is gone and everything works as expected. So it has to do with above.

@331: noticed the same thing ;-)

ok i got it down to the following code

      // Build blocks object
      if (block.search('homebox_') != -1) {
        // If block is custom, we need more data
        blocks[block] = {
          region: colIndex,
          status: visible,
          color: color,
          open: open,
          title: $(this).find('.portlet-title').html().stripTags(),
          content: $(this).find('.portlet-content').html(),
          module: 'homebox',
          delta: block.replace('homebox_', ''),
        }
      }
      else {
        blocks[block] = {
          region: colIndex,
          status: visible,
          color: color,
          open: open
        }
      }

This gives the IE7 error.

ok glad we have fixed some things... what remains?