Taking the ResourceSpace user interface to the next level

[Dan Huby]

ResourceSpace is now 6 years old, and if the same requirements were presented to me today I'd no doubt do some things differently.

Web applications that I have developed recently use jQuery and dynamic loading of partial page content and data (AJAX), rather than full page loading with the frame at the bottom for the 'fixed' element. This results in a much slicker user experience which is faster and less 'jumpy', and feels more like a conventional desktop application. Recent mainstream websites have also been following this trend.

I think it would be good to introduce these elements to ResourceSpace. In particular:

 - Migrate entirely to jQuery and possibly also jQuery UI, dropping prototype/scriptaculous.

 - Dropping frames entirely and altering the existing 'frameless' mode so it looks more like the existing frames mode, with a collection bar at the bottom, and making that the default instead (removing the config option as it becomes meaningless).

 - Altering all (or most) links so that instead of a page reload the content is loaded into a DIV tag, and the top bar / right search box / footer remain unaffected. This means the collection bar can stay on screen without being constantly reloaded (as it does currently using frames). We can dynamically update the browser URL so that it 'appears' that different URLs are being used so that copied/pasted URLs will still take the user to the right place (Facebook does this, and I have used the same technique in a recent application).

Obviously a substantial piece of work, but probably something that could be done in smaller stages.

My questions:

 1) What are your thoughts on the above?

 2) Is anyone willing to commit some time (or fund a developer) towards achieving the above goals?

Dan

[Oğuz GÜLBAY]

On 30.04.2012 12:57, Dan Huby wrote:
> Web applications that I have developed recently use jQuery and dynamic
> loading of partial page content and data (AJAX), rather than full page
> loading with the frame at the bottom for the 'fixed' element. This
> results in a much slicker user experience which is faster and less
> 'jumpy', and feels more like a conventional desktop application.
> Recent mainstream websites have also been following this trend.

Hi,

This probably won't make much of a advice, but WOW! I've been waiting
for this discussion to happen for a long time =) I bet there are a lot
of people who would definitely like this idea.

Regards,
Oğuz

[Tom Gleason]

Hi Dan,

All good ideas. I'm not sure about frameless collections mode; it seemed to create a cascading set of problems. What about first trying iframes? This is an easier switch to make since it only involves the index page. The hardest part is forcing a sticky/resizable iframe at the bottom which is still probably doable. 

Tom

Web applications that I have developed recently use jQuery and dynamic loading of partial page content and data (AJAX), rather than full page loading with the frame at the bottom for the 'fixed' element. This results in a much slicker user experience which is faster and less 'jumpy', and feels more like a conventional desktop application. Recent mainstream websites have also been following this trend.

 

--
Tom Gleason
ResourceSpace Hosting & Development

Vice President, Engineering
Colorhythm LLC
http://www.colorhythm.com

Main Office:  +1 415-399-9921
Fax: +1 253-399-9928
Mobile:  +1 347-537-8465

tgle...@colorhythm.com

[mrpatulski]

 Dan,

Glad you are bring this up. Over all these are very good questions to be asking. Could  this be an opportunity to create a roadmap for the application?

Frame vs. frameless--I think its great idea and would support it in spirit and as a Montala client. Our super-admins have been using Frameless on our install for the last week or so and really prefer it because we can see real URLs but miss the collections bar.

What Is the funding model for an effort like this--a consortium fo small donations may move it along easier that several large ones.

Cheers,

Matthew Patulski

[Paul]

I would love to see an update to the interface. In the past, the use of a template system like smarty has been discussed, and there was an effort in the past to use the Smarty template system.

In my opinion, now would be a good time to revisit this idea, and hopefully incorporate it in the new interface. I would be willing to help out on this project, and have used the Smarty in the past.

Paul

[Dan Huby]

I think including a move to Smarty in this set of developments would be a mistake as it would move back the goal posts quite considerably.

Migrating to Smarty is a huge task. It's not clear how the existing plugin hooks would work. Also there is so much logic in the front end that the templates may start to resemble the existing front end (pages/*) PHP files, so some restructuring would be necessarily to do it properly. And then this is starting to look like a full rewrite instead of an incremental upgrade.

I'm not 100% convinced Smarty is the way to go for a fairly complicated web application. It has worked well for me for websites but on web apps you can end up with templates so complicated that the exercise has become quite pointless and you may as well have used PHP (which can be quite template-like anyway).

Dan

[Dan Huby]

On Monday, April 30, 2012 1:35:09 PM UTC+1, Tom Gleason wrote:

Hi Dan,

All good ideas. I'm not sure about frameless collections mode; it seemed to create a cascading set of problems. What about first trying iframes? This is an easier switch to make since it only involves the index page. The hardest part is forcing a sticky/resizable iframe at the bottom which is still probably doable. 

I don't really see how iframes would offer any advantage over frames, other than removing the frameset. And it's not much less work than doing it properly and using AJAX.

I think the frameless collections problems were largely resolved, although it took a while as it was a little-used mode. If it was the only mechanism then I'm sure we'd work the bugs out of the system much faster.

Dan

[Dan Huby]

On Monday, April 30, 2012 1:48:52 PM UTC+1, mrpatulski wrote:

Could  this be an opportunity to create a roadmap for the application?

I'm sometimes asked for a road map but writing one (as a group) seems like a pointless task without some sort of committment or funding to guarantee that any of it would actually happen. Otherwise it's a really just a wish list, and we had one of those until I removed it because it was creating a whole load of requests along the lines of "I added XYZ to the wish list, when will it be developer?" ... i.e. it created false hope.

Some sort of co-funding effort might work but I don't know how the financials would be handled. Maybe there is some sort of crowd-funding web site out there?

My post was really start the conversation - to gauge interest, and gather ideas / momentum. I hadn't yet thought about how we might develop this. It might not need a funding model if enough developers are interested in getting involved.

[mrpatulski]

Dan,

I see your point where a feature specific roadmap may not fit this setting. But if 50 clients all paid 1/2 day dev time--25 days--for a consensus built roadmap  that is general in nature ie web standards compliance, mobile, html5 video, application documentation, etc. It may make for an easy sell at renewal time.

Cheers,

[Prashant Jagarlapudi]

Dan

I think crowdfunding is a superb idea. Kickstarter.com comes to mind.

Prashant J
(Not affiliated to Kickstarter :) )

> --
> You received this message because you are subscribed to the Google Groups
> "ResourceSpace" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/resourcespace/-/8MxwSwOTrXgJ.
> To post to this group, send email to resour...@googlegroups.com.
> To unsubscribe from this group, send email to
> resourcespac...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/resourcespace?hl=en.
>
>

--
Sent from my mobile device

[Tom Gleason]

A single page would be better for many reasons, though iframes are not as obsolete or inappropriate to consider as one might suppose. But if we want to go with AJAX (which i'm not against):

The question becomes where to draw the line between page turns and ajax. Top and bottom changing divs are the first step. We don't want to have to reload the collections 'panel' on every page turn, as frameless collections works now. That's very clear. To me, this becomes a bit complicated since we have to change the behavior of all links in the system, but using selectors based on link target, it might not be too hard.

What's going to happen, though (i've been around the block with these experiments a few times), is someone will say, "we don't even need to reload the collections items, we can just add a new div when an item is added, or remove a div when an item is removed, and then just update the db via ajax." But then you run into new issues of consistency in things such as result count and page count, and end up having to reload everything anyway. Of course it would be great to have live polling and such, like Gmail, where you just see new resources appearing or disappearing from the view. We'd just have to be careful to keep this very simple (top and bottom reloads) for now.

 

On Mon, Apr 30, 2012 at 9:35 AM, Dan Huby <d...@montala.com> wrote:

I don't really see how iframes would offer any advantage over frames, other than removing the frameset. And it's not much less work than doing it properly and using AJAX.

I think the frameless collections problems were largely resolved, although it took a while as it was a little-used mode. If it was the only mechanism then I'm sure we'd work the bugs out of the system much faster.

[Jeff Harmon]

I haven't looked at frameless collections in a while, but doesn't it lack previews? If so, that specifically is quite undesirable. 

Jeff 

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

--

You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

[Jeff Harmon]

They didn't accept our email ingest plugin. I would doubt Kickstarter would accept this.

Jeff

--
Jeff Harmon
Chief Executive Officer
Colorhythm LLC
http://www.colorhythm.com

Main Office: +1 415-399-9921
Fax: +1 253-399-9928
Mobile: +1 510-710-9590

jha...@colorhythm.com

[Dan Huby]

I meant it would work like frameless collections, but it would look pretty much exactly the same as the current frames based setup, with a collection bar at the bottom including previews.

Users shouldn't notice any difference except that the system feels more responsive, and the URL at the top will represent the current page (even though the page is not reloading).

Dan

[David Dwiggins]

I think this is a good idea. I also think it is good to keep the
changes as incremental as possible. Trying to implement something like
Smarty as part of this would turn a very small, manageable project
into something that would affect thousands of lines of code and would
likely introduce a great deal of new complexity and bugs, not to
mention breaking almost all existing plugins.

I think having a long term development roadmap might not be a bad
idea, but again I wonder if trying to do that as part of this might
lead to scope creep.

As an aside: Crowdfunding is appealing in theory, but has proved
problematic in practice. I wrote the original transform plugin using
this model, and it took a year for me to recoup the time I spent
developing it, and then only because Colorhythm stepped in and picked
up the slack for folks who didn't pay. There was also a major problem
because when 10 different people are paying, no one person is in
charge and scope creep becomes a real problem. I think the better
solution is for organizations to sponsor larger chunks of development,
or for smaller groups to band together to sponsor complete projects,
presenting a unified proposal to the developer.

Regarding the ajax collections plan, I would certainly be willing to
pitch in on some of the development work. (If nothing else, losing
Prototype would break the transform plugin and some other plugins I've
written that rely on it.)

-David

[Paul A Norman]

HI,

The core stability of RS is one of its greatest assets.

I would personally love to see any jQuery Ajax incorporated that would hold back any 'unnecessary' page/frame reloads. (There are workarounds for keeping page count/positions and DB relationships if necessary.)

I personally would love the idea of PHP 5 classes - but immeadiatley perceive that it would potentially break the core stability and backwards comparability.

But jQuery ajax for display features does not have to pose the same kind of threat.

Perhaps an inventory needs to be made of existing plug-ins and core RS functionality, and those proposing changes show in a *comprehensive* way (sort of like how companies have to to do environmental impact reports ahead of developments), how the RS ecosystem in total will be catered for in any proposed transition(s)?

Rather than just finding out as we go along, with the risk that something important is really mucked up?

Paul

[Jeff Harmon]

I agree with every word David has written and would be willing to co-fund development of an AJAXey collections panel.

Jeff

--
Jeff Harmon
Chief Executive Officer
Colorhythm LLC
http://www.colorhythm.com

Main Office: +1 415-399-9921
Fax: +1 253-399-9928
Mobile: +1 510-710-9590

jha...@colorhythm.com

[Dan Huby]

A proposed first step:

 - Inclusion of the JQuery library by default, in 'no conflict' mode so it will sit happily alongside Prototype.

 - A new config option for developers which will remove Prototype and Scriptaculous.

Developers can therefore migrate functionality over time rather than it being a single big mod (requiring branching). Note that the jQuery function must be used, not the $() alias which will still be used by prototype. We can switch to $() afterwards but it doesn't seem necessary.

I can do the above in a few minutes. Migrating functionality to JQuery may take longer but there are usually straightforward equivalents.

Once we have fully migrated to JQuery it's easier to then look at replacing the collection frame with a remotely updatable DIV and altering the way page loading works.

Dan 

[mrpatulski]

Jeff,

There are a number of software projects on Kickstarter that are open source--maybe it was the way the proposal was written? If there were an NPO component to ResourceSpace--a foundation submitting a project--it may get more traction. If the proposal was based on a consensus roadmap from NPO, NGO users that would help too. You as a for profit organization would benefit because you could then redirect your development dollars to features not available in the open-source base code to differentiate your organization.

Scenario:

1. Take a month or  2 to create consensus around said roadmap in 3 stages. 
   
2. The KS proposal could have a goal to fund 1/3 of the RM if it funds 200% second 1/3, etc. 
   
3. At the same time solicit users like me for 1/2 day dev donations as part of our service contract renewals to also support the effort specific to the roadmap.
   
4. All work would be 100% opensource.
   

http://www.kickstarter.com/discover/categories/open%20software?ref=live

Just a thought.

cheers,

Matthew Patulski

[Prashant Jagarlapudi]

Matthew

I couldn't agree more.  Kickstarter has all OpenSource projects. In addition, it is a good platform for publicity and to increase awareness.  I would be happy to help write the proposal for this project.

Regards
Prashant J

--

You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/9HtL1XxqPx4J.

[Jeff Harmon]

I had the same enthusiasm. Our proposal was for 100% open source and presented fine. It was because it wasn't a creativity-oriented enough project that Kickstarter rejected it. 

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

--

You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/9HtL1XxqPx4J.

[Jeff Harmon]

Just to be 100% clear, the plugin I proposed to KS was offered as part of the RS base code, 100% open sourced. I think there are other considerations at play in their decision process. We could try though!

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

[Jeff Harmon]

I see no evidence whatsoever that KS cares about whether a submitting organization is an NPO or not. An organization's status in this regard and a software's license are separate matters. And even a for-profit organization can have more communitarian values than an NPO! 

And in the case of RS, aside from Montala's and Oxfam's exemplary founding of the application, Colorhythm has contributed more money and time to the RS open source project than anyone else in the world, NPO or not.

Life and power are more complex than ideology dictates. 

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

--

You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/9HtL1XxqPx4J.

[Henrik]

I think it’s a good idea to move to jQuery/jQuery UI and eventually drop the frames.

I think the project needs a rough roadmap – it’s important that all developers and funding customers know where the project is heading. It seems to me that it now would be a bad idea to implement a new feature using prototype/scriptaculous. But where do I find that information (apart from in this thread)?

Regarding co-funding – we may take a look at http://www.cofundos.org I have no personal experience of it, I just found it yesterday.

Best regards,
Henrik

To unsubscribe from this group, send email to resourcespace+unsubscribe@googlegroups.com.

[Paul A Norman]

> I think the project needs a rough roadmap – it’s important that all developers and funding customers know where the project is heading

Tick!

> But where do I find that information (apart from in this thread)? 

Who can update the Wiki? 

There is so much information in this group's searchable archive that is essential,, yet hard to find.

Paul

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/NN4Sqb2ppcUJ.

To post to this group, send email to resour...@googlegroups.com.

To unsubscribe from this group, send email to resourcespac...@googlegroups.com.

[Jeff Harmon]

I'd love to see what people feel is desirable. Certainly such a roadmap could help us coordinate and aim our efforts, but the funding of development is currently rather seriously out of proportion to the feature requests and visions.

The best way to get ResourceSpace to evolve where you want is to contribute or fund development. Visions are certainly very welcome but it would be naive to have the impression that a roadmap is going to direct all efforts in a linear and perfectly aimed manner.

Best,

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

[Oğuz GÜLBAY]

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/NN4Sqb2ppcUJ.

To post to this group, send email to resour...@googlegroups.com.

To unsubscribe from this group, send email to resourcespac...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/resourcespace?hl=en.

Well, I think especially some parts of the administration side of RS is lacking usability in terms of UI. Try to upload a couple of files, you're fine. You can even drag & drop them, but for instance when you try to work with users, groups, access right etc. you almost always have to type down quite a lot.

This is an end-user opinion anyway, I'm not an advanced php (or any other language for that matter) coder, but I think I've been actively using RS long enough to have a decent point of view: Administration side is definitely less user-friendly.

Regards,
Oğuz.

[Dan Huby]

> Well, I think especially some parts of the administration side of RS is lacking usability in terms of UI.

Can we stay focussed on the original goal, which is to move away from old technology (prototype, frames) towards new (jQuery, AJAX) for the core interface.

Redesigning the admin areas would be a separate project, as would adding SMARTY templates. Trying to introduce anything else is just going to cause this to stall. Feel free to start separate threads on those topics.

I would also say that coming up with a roadmap is another conversation and I've already given my thoughts on that.

Personally, I don't think crowd-funding or co-funding is necessary to achieve the goal in the thread subject and we can probably do this work between us if we put our heads together and can devote a reasonably small amount of time, each dealing with the areas we originally developed or have become responsible for to some degree.

There are just too many issues with co-funding / crowd-funding. Who gets the money, how is it distributed, how do we balance the requirements of all those funding, how do we prevent requirement becoming bloated etc.

Does anyone have an opinion on my proposed first step highlighted (way up) above?

Dan

[Jeff Harmon]

I'm with you, Dan. I like your direction and focus. How can I support you?

Jeff

--
Jeff Harmon
Chief Executive Officer
Colorhythm LLC
http://www.colorhythm.com

Main Office: +1 415-399-9921
Fax: +1 253-399-9928
Mobile: +1 510-710-9590

jha...@colorhythm.com

> --
> You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

[Paul]

I agree. Lets start with the jquery and ajax, as proposed by Dan. Once this is done, we can look to improve other areas of the

code.

Otherwise this discussion will go on and on, and nothing will get done.

Paul

 

[mrpatulski]

I second what paul, dan and jeff said.  The roadmap/funding question warrants it's own thread. Wikification of curated groups content warrants its own thread.

[David Dwiggins]

I agree with the idea of incorporating jquery in compatibility mode as
a starting point for ajaxifying some of the current functionality.
Once this is incorporated, we can start looking at how to gradually
move away from Prototype/Scriptaculous.

I also agree that these other subjects are worth considering but as
part of a separate discussion.

-David

> --
> You received this message because you are subscribed to the Google Groups
> "ResourceSpace" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/resourcespace/-/S9zRKj-S1wQJ.

[Tom Gleason]

The migration to jQuery will likely have to come before getting into ajaxification of the Collections panel, and I think there will be more work involved than Dan assumes, but not too much.

I want to reiterate one concern, that we can't be reloading the Collections panel on every page turn, so the main panel will have to be ajaxified as well (and I don't know how this might affect the goal for urls). This brings the problem beyond a restyling of the current frameless collections mode. 

If we reload the Collections panel on every page turn, there would actually be a significant *decrease* in speed.

I sent Dan a few of the simpler ports (star ratings, infobox popups). 

Reordering collections, Resource Type checkall in Simple Search, Autocompletions are among several areas yet to be addressed by someone. There are probably some others.

Annotate is based on a specific older *version* of jQuery, so we need to either work around that or see if we can hire the developer to update or clarify the incompatibility issues.

I've already ported Contact Sheets over to jquery some time ago (although the code isn't as good as what I had in prototype, but it works and can be improved at some point).

Lightbox (a functionality I've never used) is based on prototype I believe. 

Tom

--
Tom Gleason
ResourceSpace Hosting & Development

Vice President, Engineering

Colorhythm LLC
http://www.colorhythm.com

Main Office:  +1 415-399-9921
Fax: +1 253-399-9928

Mobile:  +1 347-537-8465

tgle...@colorhythm.com

[Tom Gleason]

After rereading Dan's initial post, maybe my concerns were mistaken.

 

You're planning to use pushState to modify the url while reloading the main area content?

[mrpatulski]

Jeff,

A very curious set of responses. Successful, mature, open source projects have roadmaps. from the other responses here, there seems to some desire for it at least in principal. We can start a thread to see where it can go.

In suggesting a focus on NPOs, it as more to do with WWF and Oxfam or some of the others have greater name recognition than most of the private companies who use the application  like yours or mine. Many of the software projects on kickstarter have a blended approach of profit, community building and open-source practices. This all goes to targeting the ask to the audience, nothing more.

As for your repeated claims that you are the biggest investor in RS, thank you for the spend  but you made a choice that I am sure results in a profit. It seems like, sometimes, you hold that over the rest of us who also spend thousands every year or hundreds hours of our time contributing this fine application. You might want to give it a rest.

Cheers,

Matthew Patulski

[Jeff Harmon]

Hi Matt,

I think if you reread your initial post and my replies after a little while you might gain more compassion for my angle here. Romanticizing a union between open source efforts and non-profit initiatives is a real problem, and developers often pay the most because of it, being taken for granted and undervalued. Just trying to make a living is hard enough, let alone supposedly bathing in profits! Your for-profit company dwarves mine by a factor of a gazillion and has certainly gained more money from RS than mine. So whose statements are more curious? 

You basically said that our proposal was either poorly written or was rejected because we are a for-profit company, both of which were mildly insulting and happen to be incorrect, unless we are to disbelieve Kickstarter themselves! They felt the email ingest plugin was not in line enough with their creative focus.

Back to work, my friends. I supported a roadmap, as anyone who reads carefully would have noticed. And I'm not going to give it a rest. 

Peace,

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/bT7iTyLfwS4J.

[mrpatulski]

Jeff,

We are going to have to agree to disagree on open source business practices and Kickstarter--which is fine. Shake hands and move on.

I do want to clarify for the the group on our use and support of ResourceSpace and open source software. My team is a 300+ marketing department of a global technology services company. We have been end-users of RS for 3 years. We hire developers for several weeks each year for support or new features as we need them. We contribute all of that work back to the RS  code base. We have similar relationships with developers in the WordPress and Drupal communities too. Any 'profit' the application is what we gain through efficiencies typical of other applications used to manage distributed team activities.

RS is not part of our external service offerings. If it were, the same model would be applied: RS developers would be hired and their dev work would be given back to the community. 

Hope that clears things up for everyone. It any of you have constructive criticism on how to improve our model, please contact me directly. 

RS is a great App. I like that I can use it my workplace and then turn around and use this experience to set up the same solution for local arts and education organizations that I provide  support for as a volunteer. I would like to keep working it this way with so many net positives.

Cheers,

Matthew Patulski

[Jeff Harmon]

Hi Matt,

Thanks for the peace offering. I certainly am happy to agree to disagree, though I'm not certain our disagreement is coherent!  Regarding Kickstarter, I just quoted them.  I think we should try with Kickstarter; I was just sharing my story.

Regarding OS business practices, I don't see enough evidence that you yet understand my perspective, but don't need to push it (this may be my fault, as I have communicated this in a rather densely compacted form).  I speak for everyone when I share profound gratitude for all the contributions you and your organization have made to the project, and certainly never meant to imply that Colorhythm is somehow the only party deserving of credit.  That would be crazy!  You guys are awesome and have contributed some truly amazing and integral features to RS.

I am very happy to be part of a community-oriented effort.  I value people over profits, and my company is a family.  We love participating in OS efforts in part because of the communitarian ethos.  I bring up our contributions partly in defense of Tom Gleason, whose tireless efforts not only in contributing code but in supporting the community in this group deserve deep appreciation and credit!

We are aligned in the vision of building a roadmap, improving the UI, and trying Kickstarter - all things that I thought I said before, but want to share clearly again now.  I and my team want to be a part of this shared effort.

Yours truly,
Jeff

Cheers,

Matthew Patulski

--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/jAS5E1uvVK8J.

[Dan Huby]

I've taken the first step in this direction:

The latest jQuery is now included on all pages, in "noConflict" mode which means it shouldn't interfere with prototype - but also that jQuery() must be used instead of $(), at least until we remove prototype.

Developers can add $disable_prototype=true to their include/config.php to remove prototype for testing purposes, i.e. to assess which parts of the system no longer work.

Also, some parts of the system (e.g. annotate) deliberately include older jQuery versions and I've left that in place for the moment until Tom has investigated further.

I've created a page on the Wiki we can use to track progress:

http://wiki.resourcespace.org/index.php/Migration_to_jQuery

http://wiki.resourcespace.org/index.php/Migration_to_jQuery

Devs, please feel free to put your name against a section of you want to handle the port and add commentary as necessary (and new sections if I've missed anything)

Tom, please can you commit those patches you sent now.

To address Tom's concern:

> I want to reiterate one concern, that we can't be reloading the Collections panel on every page turn, so the main panel will have to be ajaxified as well (and I don't know how this might affect the goal for urls). This brings the problem beyond a restyling of the current frameless collections mode.

The key is that there will be minimal page turns, with most operations (resource view, edit, search etc.) keeping the user in place on the same page but replacing the main content area. Standard anchor links and form posts will need to be changed, ideally via the use of simple wrappers, so that they no longer reload the whole page but perform a jQuery load or post operation.

The apparent URL can be changed via JS - I've done this on other projects and it works well. It means that the URL is still meaningful and if copied/e-mailed etc. it will still take the user to the right place. The downside is that it doesn't work on IE (at least < version 8) but I don't think we can worry about ancient versions of IE forever.

I think these are longer term issues though and for now if we can get all of the system using the latest jQuery, and can remove Scriptaculous / Prototype then that will be a very good start.

Thanks to everyone who volunteered to help with this. I'm really looking forward to using the new slicker ResourceSpace UI.

Dan

[Dan Huby]

An update on progress.

Tom has ported the slideshow and star rating functionality.

I've ported most of the autocomplete functionality to new functionality provided by jQueryUI. There are some other nice things in jQueryUI we might want to make use of, for example the date selector which could replace the date field and also things like the user expiry / collection share expiry dates.

What's left:

There are a number of places where prototype syntax $('objectid') is used simply to access a DOM object - these can be replaced with either the jQuery syntax jQuery('#objectid') or simply the native javascript document.getElementById().

Beyond that, I don't think there's much else to do and at that point we can remove prototype/scriptaculous and treat anything further we spot as bugs.

We'll then be 100% jQuery/jQueryUI and will be able to use this to drop the frames and make the user interface more snappy by loading parts of the page rather than the whole thing.

Dan

[Dan Huby]

Tom has ported the slideshow and star rating functionality.

Sorry, I meant infobox not slideshow. However my colleague Neil has ported the slideshow. Neil has been working on the home page slideshow and making it possible to link the slides back to the resources they were created from and the switch to jQuery was done as part of that.

Dan

 

[Paul]

Just wanted to thank all who were involved with these changes, for their efforts

Paul

 

[David Dwiggins]

Hi, Dan,

Just a heads up that I believe transform still relies on prototype. I will try to look into changing this, but may not get to it right away. In the meantime, I imagine we could set it up to load only on the individual page where it is needed...

-DD

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/2DwG4zFk-SQJ.

[Dan Huby]

On 5 Jul 2012, at 12:50, David Dwiggins wrote:

> Hi, Dan,
>
> Just a heads up that I believe transform still relies on prototype. I will try to look into changing this, but may not get to it right away. In the meantime, I imagine we could set it up to load only on the individual page where it is needed...

Thanks for the heads-up.

I think it would be acceptable to place prototype within the plugin folder, if it's not trivial to port it. Hopefully though there will be equivalent functions in jQuery or jQueryUI.

Dan

[Dan Huby]

An update on progress.

I believe I've migrated all the remaining core functionality over to jQuery. Thanks to Tom who had done some initial work on this.

I've therefore removed Prototype and Scriptaculous, and we can treat anything I've missed as a bug. Hopefully I've caught the vast majority of protoype code.

If you maintain a plugin that uses Prototype, I think it's acceptable for it to include its own copy of prototype.js, at least as a temporary work-around until you can port to jQuery.

Dan

[David Dwiggins]

Dan -- I still haven't had a chance to work on Transform. Did you test to ensure it still works after your changes? I think since it's a bundled plugin this probably needs to be addressed pretty quickly.

I am flat out today, but can try to take a look at it asap if you haven't already. (Should be a pretty quick fix to just move the necessary files to the plugin folder and change the script link.)

I still want to try to reimplement the whole thing with jquery, but haven't had the time to work on it yet.

-DD

Dan

--
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/ujjbfp1x2RwJ.

[Dan Huby]

Hi David,

A good point - I'll make that change now.

Dan

[Dan Huby]

That's been done - transform now uses a local copy of prototype/scriptaculous.

Dan

On 20 Jul 2012, at 16:11, David Dwiggins wrote:

[David Dwiggins]

Thanks!

[Dan Huby]

I've made some progress on the AJAX dynamic loading. It was surprisingly easy, largely due to the way ResourceSpace is set up with the large CentralSpace div used for the majority of page content.

I've committed the work so far to Subversion and would welcome feedback and results of testing. Hopefully you will agree that ResourceSpace feels smoother and more responsive.

To make it as easy as possible to upgrade existing code to use this there is an extra function ("CentralSpaceLoad") that can be added to an OnClick event for existing anchors. It takes two parameters - the first is the anchor element for which you simply state 'this' (used to read the URL to post to), the second is a boolean and determines if the page should be scrolled back up to the top of the screen on clicking - useful when changing pages. And that's all there is to it. Devs may want to read through the SVN commit (r3727) to get an idea of how to add this.

When clicking, the function reads the URL from the anchor, adds an 'ajax=true' parameter to it - which will disable headers and footers for the loaded content - and fetches the page from the server loading the contents into CentralSpace.

I've added this function to several links already.

There are a few situations where an AJAX load will not be performed even if the function is called. In these events a normal full page load will be executed instead, automatically.

 - Where the CentralSpace div does not exist, for example if the current page does not contain one.

 - When jumping between folders, e.g. linking to the 'pages/team/' pages from a page in 'pages/' and vice versa. This is because loading content from one level into a page from another level will cause relative path issues. Team centre pages assume a /pages/team path which is not the case if a team centre page is loaded into a page from the lower level. A longer term solution is to move to absolute paths throughout the system but this is a large job and will potentially affect plugins too. So the short term fix is simply to detect level changes and load normally instead.

 - Where JavaScript is not enabled, as the anchor tag will still work normally (OK, large parts of the rest of the system will not work, but it can't hurt to scale back where possible)

I need to add a similar function that can be added to the OnSubmit even for forms, which will work in a similar way and perform a post via AJAX.

The plan is to move as much as possible over to this system, minimising page loads. Once page loads are at an absolute minimum it becomes feasible to talk about dropping frames and having the collection bar as a div across the bottom of the screen.

Dan

[njenney]

It is unbelievable how snappy it is. I have been testing for an hour and have not found any issues other than for some reason my Geo map is no longer displaying. That may be unrelated to this change though. Awesome job.

[Dan Huby]

I've been having intermittent geomap issues too but have not been able to track it down yet.

I've fixed a glitch with the home page slideshow and also the infobox, neither of which worked properly when loaded via AJAX. I've also just noticed that the contact sheet page doesn't work when loaded via AJAX.

The issue is that some pages load JavaScript by inserting it into the page header, and the page header is not included with an AJAX load. So they need to be switched over so the JS loads inline instead.

Dan

> --
> You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/resourcespace/-/HSfTFQsU3yEJ.