Gary Gilbert raised an interesting point this afternoon talking about design in the context of uPortal. He pointed out that sometimes the problem is that the designers don't have the ability themselves to implement their design improvements and don't get enough time and effort and attention from the developers.
Well, what if we gave the designers some developers? Not just discussions, not just a chance to convince the developers to do things. No. Real actual resources - developers who make reality the vision of the designer.
Monday, September 11, 2006
Wednesday, August 30, 2006
Sakai Programmer Jobs at Yale
Yale University has two new programmer positions in their Academic Media & Technology unit. The focus of these positions is the development of
teaching and learning tools that integrate with Yale's Sakai-based learning management system Classes*v2.
Details for the positions are available online.
You can also contact the hiring manager Michael Appleby
As posted by Chuck Powell to the Sakai Announcements email list.
Yale's a really neat place to work and New Haven an awesome place to live.
Sunday, August 20, 2006
On the use of Hibernate
Someone asked me today whether uPortal uses Hibernate. Per my preferred approach of being as open as possible about as much as possible, this is mostly what I said:
No version of uPortal 2.x uses Hibernate for anything and therefore no uPortal 2.x release of any flavor includes it.
The quickstart (and the slowstart) versions of uPortal 2.x for as long as I can remember ship with and use by default HSQLDB, an in-memory database, for demonstration purposes.
A pain point in uPortal 2.x is its *not* using an ORM framework like Hibernate and therefore its baking-in of hard coded SQL statements. It does some heroics to provide a general XML language for describing the desired initial schema and data content of the database and to provision that database. There are advanced features for upgrading the database automatically.
Frankly, this is the kind of academic brilliance that is both uPortal's strength and its curse. I wouldn't trust these advanced upgrade facilities without paying a whole lot of attention to the log of what they did, and with that amount of attention I can just perform schema updates manually.
A fine alternative to automating the schema and database update process is to carefully craft upgrade SQL scripts for each supported platform. The schemas don't change enough for this to be prohibitive, and when they do change, it's worth being very sure and careful about that change. You're typically supporting uPortal on a few (one?) very specific platforms through a few very specific upgrades.
In any case, in uPortal the DBLoader functionality handles cross-database initial provisioning, and adding another supported database for initial provisioning is not hard.
At runtime, uPortal also does some heroics to flavor-test the underlying database and to choose SQL syntax -- join syntax and the like -- and in some places outright chooses among multiple available SQL statements to work in whatever RDBMs we're running against.
This pain point is real -- if you point it to another database, it probably won't work until you go adjust the SQL -- and yet it is one that I think is greatly overstated. The introduction of DAOs and a wiring framework to choose DAOs that fit with the chosen database is an excellent architectural step forward and would allow the framework itself to support wiring in different DAO impls where that non-lowest-common-denominator-SQL really is buying something.
However, doing this for uPortal 2 would not be hard and would be valuable. It might not look very pretty especially first off. First off we do something awful like externalize the SQL and let people swap properties files. This fixes the problem at the expense of locality -- I'm convinced by the points in Rod Johnson's book on this topic. So the next step would be to re-embed the SQL in DAO implementations that are generic or specific and multiple as necessary. And adopt Spring as the sane wiring mechanism to choose among these.
We're still not talking an insurmountable work, but there we have a solution wherein you can rapidly follow a recipe to choose the impls specific to your database yet replace any given impl. If you've invested in an Oracle database and want to get actual value out of that massive investment by composing stored procedures and views and the like, this is how you do that.
uPortal 3 adopts Hibernate, behind Spring-wired DAOs so that you could still replace any given hibernate-implemented DAO with an RDBMS-specific DAO implementing institution-local data access behaviors, such as accessing that expensive database's stored procedures. It still uses Dbloader-improved functionality for seeding the database. Hibernate solves the cross-platform data access problem.
uPortal 3 also introduces a comprehensive caching layer wherein almost all DAOs are fronted by "Registries" that implement caching, such that many queries will not hit the database. Ideally all caching occurs at this layer and fronting code always consults the Registry, solving another pain point of updated data not being reflected in some places in uPortal 2 without a restart. (Under the uP3 approach, just flush the registry using a convenient administrative portlet).
No version of uPortal 2.x uses Hibernate for anything and therefore no uPortal 2.x release of any flavor includes it.
The quickstart (and the slowstart) versions of uPortal 2.x for as long as I can remember ship with and use by default HSQLDB, an in-memory database, for demonstration purposes.
A pain point in uPortal 2.x is its *not* using an ORM framework like Hibernate and therefore its baking-in of hard coded SQL statements. It does some heroics to provide a general XML language for describing the desired initial schema and data content of the database and to provision that database. There are advanced features for upgrading the database automatically.
Frankly, this is the kind of academic brilliance that is both uPortal's strength and its curse. I wouldn't trust these advanced upgrade facilities without paying a whole lot of attention to the log of what they did, and with that amount of attention I can just perform schema updates manually.
A fine alternative to automating the schema and database update process is to carefully craft upgrade SQL scripts for each supported platform. The schemas don't change enough for this to be prohibitive, and when they do change, it's worth being very sure and careful about that change. You're typically supporting uPortal on a few (one?) very specific platforms through a few very specific upgrades.
In any case, in uPortal the DBLoader functionality handles cross-database initial provisioning, and adding another supported database for initial provisioning is not hard.
At runtime, uPortal also does some heroics to flavor-test the underlying database and to choose SQL syntax -- join syntax and the like -- and in some places outright chooses among multiple available SQL statements to work in whatever RDBMs we're running against.
This pain point is real -- if you point it to another database, it probably won't work until you go adjust the SQL -- and yet it is one that I think is greatly overstated. The introduction of DAOs and a wiring framework to choose DAOs that fit with the chosen database is an excellent architectural step forward and would allow the framework itself to support wiring in different DAO impls where that non-lowest-common-denominator-SQL really is buying something.
However, doing this for uPortal 2 would not be hard and would be valuable. It might not look very pretty especially first off. First off we do something awful like externalize the SQL and let people swap properties files. This fixes the problem at the expense of locality -- I'm convinced by the points in Rod Johnson's book on this topic. So the next step would be to re-embed the SQL in DAO implementations that are generic or specific and multiple as necessary. And adopt Spring as the sane wiring mechanism to choose among these.
We're still not talking an insurmountable work, but there we have a solution wherein you can rapidly follow a recipe to choose the impls specific to your database yet replace any given impl. If you've invested in an Oracle database and want to get actual value out of that massive investment by composing stored procedures and views and the like, this is how you do that.
uPortal 3 adopts Hibernate, behind Spring-wired DAOs so that you could still replace any given hibernate-implemented DAO with an RDBMS-specific DAO implementing institution-local data access behaviors, such as accessing that expensive database's stored procedures. It still uses Dbloader-improved functionality for seeding the database. Hibernate solves the cross-platform data access problem.
uPortal 3 also introduces a comprehensive caching layer wherein almost all DAOs are fronted by "Registries" that implement caching, such that many queries will not hit the database. Ideally all caching occurs at this layer and fronting code always consults the Registry, solving another pain point of updated data not being reflected in some places in uPortal 2 without a restart. (Under the uP3 approach, just flush the registry using a convenient administrative portlet).
Tuesday, August 01, 2006
On Googleability and Hyperlinkability
This is something I wrote some time ago when I was at Yale University's Technology and Planning group. Note that gmane has addressed some of my concerns.
The Sakai Communications Working Group recently polled a list I'm on for feedback about the tools in support of collaborating on Sakai. This is what I had to say:
My comments are specifically about googleability and hyperlinkability as important features in collaboration software in support of Sakai-related work.
Email archives within Sakai currently lack several key features. Firstly, the archives are not Google-indexable. This means that content on otherwise public lists (such as sakai-user, sakai-dev, sepp-ent, etc.) to which anyone can subscribe and which anyone can browse by creating an account on collab.sakaiproject.org are not searchable via a generic web search, e.g. from www.google.com.
Secondly (and technically related), these archives are not hyperlinkable. I can't (or at least, I don't see how to) produce a hyperlink that will take you directly to an archived message.
The combination of not having these two features makes Sakai email archives less valuable than they might otherwise be.
Other list archival software has these features.
It would be an improvement for the public Sakai email lists to have archives with these features. This can probably be accomplished as a supplemental email archive driven by an archival user / email address subscribed to the lists.
The advantages of Googleability and hyperlinkability of email archives is that the conversations on the email lists can later be used with minimum additional effort to answer questions on list (Your question was answered in this email thread) or to avoid questions needing to be brought up on list again, because answers are found via Google searches.
Making conversations on the email lists transparently and automatically made Googleable and hyperlinkable frees the harvesting of information from the list archives into places like the SakaiPedia to be more of an adding-value effort of organizing and refining the product of discussions on the list, and less of a required effort to make content Googleable and hyperlinkable.
Using Sakai Resources as the mechanism whereby PDFs, Word documents, Powerpoints, and other documents are distributed does currently offer hyperlinkability.
This link will take you to a particular Minutes of the SEPP-Enterprise working group:
A minutes of the SEPP-Enterprise working group
However, such links do not often become Google indexed.
Contrastingly, placing documents in a publicly-accessible Apache folder, for instance, does make them available for Google indexing:
Dr. Chuck's talks
A powerpoint from among Dr. Chuck's talks
I'd suggest that publicly available documents used for Sakai collaboration that are currently stored as archived attachments to email messages, as Resources in the collab.sakaiproject.org Sakai instance, as attachments to Wiki pages, would ideally be presented at URLs such that Google is able to index them and they can be included in Google search results. This gets maximum value out of a document-production investment.
One way to go about achieving this would be to make Sakai able to produce Apache-like directory indexes of content.
http://collab.sakaiproject.org/access/content/
Would produce a directory-index-like list of links to corresponding to sites with publicly available content. Those links might look something like this:
http://collab.sakaiproject.org/access/content/group/1103227538796-57571/
and would produce a directory-index-like list of links to folders of content, the content tree, ultimately providing links to actual entries.
Google's entry point becomes
http://collab.sakaiproject.org/access/content/
from which it can find and index all the publicly-available content.
In general it's important that as much content as possible is available without logging in, at URLs that Google can find, follow, and index, and that can be bookmarked, shared.
Best wishes in this endeavor. I hope these comments will help inform the effort.
The Sakai Communications Working Group recently polled a list I'm on for feedback about the tools in support of collaborating on Sakai. This is what I had to say:
Please contact the Sakai Communications WG at sakai-comm@collab.sakaiproject.org with any comments. Thanks in advance for any feedback.
Most importantly, we want to know how you use the current collaborative tools available to the Sakai community (Confluence, Jira, SakaiCollab, Project MatchmakingTool, etc.) What do you like or dislike about the current format? What is the most important feature for you in collaborating with others?
My comments are specifically about googleability and hyperlinkability as important features in collaboration software in support of Sakai-related work.
Email archives within Sakai currently lack several key features. Firstly, the archives are not Google-indexable. This means that content on otherwise public lists (such as sakai-user, sakai-dev, sepp-ent, etc.) to which anyone can subscribe and which anyone can browse by creating an account on collab.sakaiproject.org are not searchable via a generic web search, e.g. from www.google.com.
Secondly (and technically related), these archives are not hyperlinkable. I can't (or at least, I don't see how to) produce a hyperlink that will take you directly to an archived message.
The combination of not having these two features makes Sakai email archives less valuable than they might otherwise be.
Other list archival software has these features.
It would be an improvement for the public Sakai email lists to have archives with these features. This can probably be accomplished as a supplemental email archive driven by an archival user / email address subscribed to the lists.
The advantages of Googleability and hyperlinkability of email archives is that the conversations on the email lists can later be used with minimum additional effort to answer questions on list (Your question was answered in this email thread) or to avoid questions needing to be brought up on list again, because answers are found via Google searches.
Making conversations on the email lists transparently and automatically made Googleable and hyperlinkable frees the harvesting of information from the list archives into places like the SakaiPedia to be more of an adding-value effort of organizing and refining the product of discussions on the list, and less of a required effort to make content Googleable and hyperlinkable.
Using Sakai Resources as the mechanism whereby PDFs, Word documents, Powerpoints, and other documents are distributed does currently offer hyperlinkability.
This link will take you to a particular Minutes of the SEPP-Enterprise working group:
A minutes of the SEPP-Enterprise working group
However, such links do not often become Google indexed.
Contrastingly, placing documents in a publicly-accessible Apache folder, for instance, does make them available for Google indexing:
Dr. Chuck's talks
A powerpoint from among Dr. Chuck's talks
I'd suggest that publicly available documents used for Sakai collaboration that are currently stored as archived attachments to email messages, as Resources in the collab.sakaiproject.org Sakai instance, as attachments to Wiki pages, would ideally be presented at URLs such that Google is able to index them and they can be included in Google search results. This gets maximum value out of a document-production investment.
One way to go about achieving this would be to make Sakai able to produce Apache-like directory indexes of content.
http://collab.sakaiproject.org/access/content/
Would produce a directory-index-like list of links to corresponding to sites with publicly available content. Those links might look something like this:
http://collab.sakaiproject.org/access/content/group/1103227538796-57571/
and would produce a directory-index-like list of links to folders of content, the content tree, ultimately providing links to actual entries.
Google's entry point becomes
http://collab.sakaiproject.org/access/content/
from which it can find and index all the publicly-available content.
In general it's important that as much content as possible is available without logging in, at URLs that Google can find, follow, and index, and that can be bookmarked, shared.
Our goal is a simple way to access and learn about existing projects, to start development on new projects, and to disseminate information to the community. This environment will give the public a straightforward way to browse existing Sakai tools and participate in tool and/or core development. Our goal is to have a board approved tool and model by December the latest.
Best wishes in this endeavor. I hope these comments will help inform the effort.
JA-SIG favorably mentioned in Campus Technology
JA-SIG was favorably mentioned in Campus Technology magazine.
For colleges and universities interested in learning more about open source, fear not: There is an organization to help. It is JA-SIG, an international consortium of higher education institutions focused on promoting and sponsoring open source projects that serve colleges and universities...
Friday, July 28, 2006
Mainstream hosting versus rolling our own: availability for mashups?
One interesting thing to say about the Ohloh service is that it demonstrates the difference in consequences between using mainstream project hosting and rolling our own project hosting infrastructure in JA-SIG.
Projects hosted on dev.java.net are indexed and included in the visibility in ohloh.net, whereas by squirreling our code out into our own ja-sig.org infrastructure, our code isn't available for first pass indexing.
This is not the end of the world, of course -- presumably ohloh can and will eventually get around to indexing Sakai and uPortal, but the CAS Modules and Spring project and so forth show up immediately, thereby getting better visibility in these mashups, or even just when someone searches dev.java.net or sourceforge.
Sakai is present on dev.java.net but there's no code there so Sakai's ohloh.net entry is dopey by default.
uPortal isn't even on the radar at ohloh.net because it's not on one of the hosts being indexed. So if you search for opensource portals there, uPortal won't even show up.
Projects hosted on dev.java.net are indexed and included in the visibility in ohloh.net, whereas by squirreling our code out into our own ja-sig.org infrastructure, our code isn't available for first pass indexing.
This is not the end of the world, of course -- presumably ohloh can and will eventually get around to indexing Sakai and uPortal, but the CAS Modules and Spring project and so forth show up immediately, thereby getting better visibility in these mashups, or even just when someone searches dev.java.net or sourceforge.
Sakai is present on dev.java.net but there's no code there so Sakai's ohloh.net entry is dopey by default.
uPortal isn't even on the radar at ohloh.net because it's not on one of the hosts being indexed. So if you search for opensource portals there, uPortal won't even show up.
Job Opportunity at BU
BU's School of Management is now taking applications for a Senior Software Engineer position (see entry 3175/G256 on the university's IT jobs page).
As posted on sakai-announce.
We're especially interested in the sort of facility that comes from healthy experience in open source endeavors, so it seems fitting to circulate the announcement here. Feel free to contact me for any further details:
clayf AT bu.edu.
As posted on sakai-announce.
Tuesday, June 27, 2006
How to make the varsity team
Sadly, uPortal didn't make this list of recommended portals. Why? Well, the categories of recommendation are a little elucidating. uPortal needs to be better at:
I would have thought that uPortal was already way ahead on "extensibility of architecture", with XSLT templating technology, exceptionally powerful groups and permissions, an excellent and pluggable DLM layout manager, and ever increasing Springy declarative configuration, with a rosy expected future of all-Spring-all-the-time in uPortal 3, Peter's highly pluggable rendering pipeline, and Mark's pointedly pluggable parameter processing pipeline for the next rev of DLM. And of course pluggable error rendering, still one of my favorite features ever. Awareness of the extensibility of uPortal is less than it ought to be and there are things we could do in the documentation and web presence to raise awareness of the uPortal strengths.
Far to go and much to learn. But uPortal is still an excellent portal as is and I would have liked to have seen it make the list.
- Ease of installation
- Number and usefulness of included portlets
- Extensibility of architecture
I would have thought that uPortal was already way ahead on "extensibility of architecture", with XSLT templating technology, exceptionally powerful groups and permissions, an excellent and pluggable DLM layout manager, and ever increasing Springy declarative configuration, with a rosy expected future of all-Spring-all-the-time in uPortal 3, Peter's highly pluggable rendering pipeline, and Mark's pointedly pluggable parameter processing pipeline for the next rev of DLM. And of course pluggable error rendering, still one of my favorite features ever. Awareness of the extensibility of uPortal is less than it ought to be and there are things we could do in the documentation and web presence to raise awareness of the uPortal strengths.
Far to go and much to learn. But uPortal is still an excellent portal as is and I would have liked to have seen it make the list.
Monday, June 26, 2006
How UE designers can help with uPortal
Someone recently emailed me to ask about getting involved with uPortal. I answer here in the interest of transparency and getting word out that your involvement is welcome.
Welcome! I'm sure you can help.
The case for englightened self interest:
I'll address the question of what the project needs, but let me first articulate this: the project needs what you need. We're not looking for martyrs to do a lot of work out of the goodness of their hearts (any would-be martyrs are welcome, but you're not what we're building this project on). What is needed, what is sustainable and what works, is for people to do work that makes sense from their own perspective.
It's a matter of a community of collaborators acting under an approach of enlightened self-interest, rather than a centrally organized commune.
So, for instance, you might need a portal. And you might need that portal to not look brown and drab, you might need it to support drag and drop user experiences for portal customization, you might need it to use nested divs instead of nested tables, and you might need it to support interesting ajax callbacks. Or maybe you just need it to have a little spiffier documentation. It turns out, there are lots of other people who need these things too. And if you speak up on the list and find some of them, they may be available to collaborate and help design/work on/QA these enhancements. Or you may develop them all on your own but then seek to re-integrate them with the core uPortal so that others will help maintain them and you'll experience a lower total cost of ownership of your portal.
Or maybe you don't immediately need a portal, but you're looking for some interesting projects and an opportunity to collaborate with the smart, fun, and good-looking JA-SIG community. It's a little harder to tell collaboration stories that work when you're not looking to yourself put the portal into production, but this can work.
So, as you read through some descriptions of what uPortal needs, be sure to think about what you need, what needs you think are shared between you and other uPortal deployers, because really, uPortal doesn't need from you anything more than the intersection of what you need and what our current and would-be deployers need.
What uPortal needs from User Experience developers:
uPortal needs a more attractive out of the box skin. Jason Shao and others have worked on this for uPortal 2.6 (the current HEAD of the portal CVS project) -- that work needs engagement and validation by additional developers and the issue of whether and what to do about the default skin in uPortal 2.5 is certainly still open for discussion. For the right skin, I think it absolutely would be worth the pain of a skin upgrade in the patches branch. A modern skin would improve the marketabilty of uPortal.
uPortal needs more attractive optional additional example skins, ideally with good instructions and an easy migration path to turn them on. More showcasing of what can be done with uPortal.
uPortal needs to close the gap between DLM and ALM and SLM theme transforms and more generally improve the pluggability and re-usability of skins. It would be oh so awesome if skins were modularized such that we could just pass them around, at least for the 80% most modest theme transform needs. There will always be the opportunity for advanced hacks to produce cooler user experiences, and that's a good thing, but the majority of sites should be able to settle on a common set of user experience functionality and share neat skins.
uPortal needs more and better how-tos and documentation for producing these awesome skins. It needs UE people to come to our conferences and developer meetings en-masse and form a more visible and active presence in our community.
The uPortal project itself needs improvements to its web presence, and there's a jasig-webpresence email list for discussing and working on just this topic. We need User Experience exports to join in those dicussions and pick up some of that work. What would a compelling and inviting developer.ja-sig.org homepage look like? While I appreciate the efforts of those who have set up what we've got, what we've got isn't it. We need User Experience experts to help us make our Wiki more usable and our website more compelling.
We have a new and growing process for accumulating, prioritizing, and matchmaking around requirements, and we need articulate, thoughtful, excellent User Experience requirements to go into that process. Yes, we all know we need Drag and Drop. Now what does it really look like? How does it feel? What really neat user experience stories could go into this process that would get people excited?
And in the meantime, are there pokey corners we can easily round to ease the user experience of our product? We need bugs fixed and minor enhancement requests worked on, and while many of the bugs are Java bugs that require java developers, some of them can be addressed in XSLT, which is sometimes the domain of UE developers, and many of the issues could benefit by the input of UE designers to ensure that what is produced is not only functionally complete but also usable.
One of the tragedies of our project is that we standardized on a layout manager that fails to showcase some of our best features. User experience designer input could have brought about implementing a UI for configuring those pesky restrictions and prioritizations of fragments, for subscribe time parameter value solicitation from end users. Let's not make that mistake again: user experience experts can help the project put its best foot forward in showing off the powerful capabilities that lie beneath.
We need user experience input and work both in uPortal 2 and in uPortal 3.
But mostly, we need what you user experience designers need: a flexible and powerful portal platform in which the shared problems are solved via collaboration and the extension points and support is there for you to fly free in solving your local problems and adding your branding and local value-add. We need your help to be the portal that you love to use. And you need to help because you'll love to have a better portal.
A reminder that uPortal is best discussed on the uPortal project lists:
While I try to be available off-list and politely and usefully answer questions sent my way (trying to get better at this), really the very best place to discuss uPortal is on the project lists. We have a list jasig-portal for general discussion of using uPortal, and a list jasig-dev for discussion of active development on the uPortal project itself. We also have a cluster of fringe lists for discussing user expereince, the JA-SIG web presence, uPortal 3 as it exists in the sandbox, and JA-SIG operational issues. If there's a niche for discussion that we don't yet have a list for, let's make one and start discussing and building an archive that can be valuable to others even after the discussions conclude.
While off-list discussions are often useful, they are a tool to be soberly considered because they often miss opportunities for wider involvement, transparency, and archival for future interest.
Hi, I'm a Graphic Designer/Developer. I currently create Web Based Training for [a large organization]. I came across uPortal and noted the need for UE designers. I would like to know more about what the project needs and see if I can help at all.
Welcome! I'm sure you can help.
The case for englightened self interest:
I'll address the question of what the project needs, but let me first articulate this: the project needs what you need. We're not looking for martyrs to do a lot of work out of the goodness of their hearts (any would-be martyrs are welcome, but you're not what we're building this project on). What is needed, what is sustainable and what works, is for people to do work that makes sense from their own perspective.
It's a matter of a community of collaborators acting under an approach of enlightened self-interest, rather than a centrally organized commune.
So, for instance, you might need a portal. And you might need that portal to not look brown and drab, you might need it to support drag and drop user experiences for portal customization, you might need it to use nested divs instead of nested tables, and you might need it to support interesting ajax callbacks. Or maybe you just need it to have a little spiffier documentation. It turns out, there are lots of other people who need these things too. And if you speak up on the list and find some of them, they may be available to collaborate and help design/work on/QA these enhancements. Or you may develop them all on your own but then seek to re-integrate them with the core uPortal so that others will help maintain them and you'll experience a lower total cost of ownership of your portal.
Or maybe you don't immediately need a portal, but you're looking for some interesting projects and an opportunity to collaborate with the smart, fun, and good-looking JA-SIG community. It's a little harder to tell collaboration stories that work when you're not looking to yourself put the portal into production, but this can work.
So, as you read through some descriptions of what uPortal needs, be sure to think about what you need, what needs you think are shared between you and other uPortal deployers, because really, uPortal doesn't need from you anything more than the intersection of what you need and what our current and would-be deployers need.
What uPortal needs from User Experience developers:
uPortal needs a more attractive out of the box skin. Jason Shao and others have worked on this for uPortal 2.6 (the current HEAD of the portal CVS project) -- that work needs engagement and validation by additional developers and the issue of whether and what to do about the default skin in uPortal 2.5 is certainly still open for discussion. For the right skin, I think it absolutely would be worth the pain of a skin upgrade in the patches branch. A modern skin would improve the marketabilty of uPortal.
uPortal needs more attractive optional additional example skins, ideally with good instructions and an easy migration path to turn them on. More showcasing of what can be done with uPortal.
uPortal needs to close the gap between DLM and ALM and SLM theme transforms and more generally improve the pluggability and re-usability of skins. It would be oh so awesome if skins were modularized such that we could just pass them around, at least for the 80% most modest theme transform needs. There will always be the opportunity for advanced hacks to produce cooler user experiences, and that's a good thing, but the majority of sites should be able to settle on a common set of user experience functionality and share neat skins.
uPortal needs more and better how-tos and documentation for producing these awesome skins. It needs UE people to come to our conferences and developer meetings en-masse and form a more visible and active presence in our community.
The uPortal project itself needs improvements to its web presence, and there's a jasig-webpresence email list for discussing and working on just this topic. We need User Experience exports to join in those dicussions and pick up some of that work. What would a compelling and inviting developer.ja-sig.org homepage look like? While I appreciate the efforts of those who have set up what we've got, what we've got isn't it. We need User Experience experts to help us make our Wiki more usable and our website more compelling.
We have a new and growing process for accumulating, prioritizing, and matchmaking around requirements, and we need articulate, thoughtful, excellent User Experience requirements to go into that process. Yes, we all know we need Drag and Drop. Now what does it really look like? How does it feel? What really neat user experience stories could go into this process that would get people excited?
And in the meantime, are there pokey corners we can easily round to ease the user experience of our product? We need bugs fixed and minor enhancement requests worked on, and while many of the bugs are Java bugs that require java developers, some of them can be addressed in XSLT, which is sometimes the domain of UE developers, and many of the issues could benefit by the input of UE designers to ensure that what is produced is not only functionally complete but also usable.
One of the tragedies of our project is that we standardized on a layout manager that fails to showcase some of our best features. User experience designer input could have brought about implementing a UI for configuring those pesky restrictions and prioritizations of fragments, for subscribe time parameter value solicitation from end users. Let's not make that mistake again: user experience experts can help the project put its best foot forward in showing off the powerful capabilities that lie beneath.
We need user experience input and work both in uPortal 2 and in uPortal 3.
But mostly, we need what you user experience designers need: a flexible and powerful portal platform in which the shared problems are solved via collaboration and the extension points and support is there for you to fly free in solving your local problems and adding your branding and local value-add. We need your help to be the portal that you love to use. And you need to help because you'll love to have a better portal.
A reminder that uPortal is best discussed on the uPortal project lists:
While I try to be available off-list and politely and usefully answer questions sent my way (trying to get better at this), really the very best place to discuss uPortal is on the project lists. We have a list jasig-portal for general discussion of using uPortal, and a list jasig-dev for discussion of active development on the uPortal project itself. We also have a cluster of fringe lists for discussing user expereince, the JA-SIG web presence, uPortal 3 as it exists in the sandbox, and JA-SIG operational issues. If there's a niche for discussion that we don't yet have a list for, let's make one and start discussing and building an archive that can be valuable to others even after the discussions conclude.
While off-list discussions are often useful, they are a tool to be soberly considered because they often miss opportunities for wider involvement, transparency, and archival for future interest.
Power law of participation
The Power Law of Participation provides context to describe what we're trying to do in JA-SIG, and for describing our challenges. How do we make the shallow end of the curve less steep, and better enable casual participation? How do we make it attractive to draw further up the curve into more active participation?
Thursday, June 22, 2006
Injecting Spring managed beans into IChannels
Someone wrote me to ask my thoughts on injecting Spring-managed beans into IChannels. This is what I had to say.
It's an approach. Channels are tightly coupled to uPortal anyway, so being tightly coupled to the context façade and looking up magic beans by name isn't the end of the world. This approach has the advantage of feeling a lot like our crufty static services invocation approach to life -- the Lookup (anti-)pattern.
I'm very attracted to going a step further and using ChannelToBeanProxy where the proxy IChannel looks up a named IChannel bean from the PortalApplicationContextFacade. Then you can wire in your Spring-managed beans to the channel, potentially wire in different service realizations or different proxies on top of services into different channels, etc. Gets a little closer to dependency injection.
Whether you inject into a Spring-managed IChannel instance or you write an IChannel that looks up the beanfactory and beans it needs probably isn't that different, though.
It's not that ugly, and we really need to get there. Step one was what we did. Next step is to really buy Spring, use a Spring-provided context listener to bootstrap, and then use a uPortal-provided secondary context listener to expose that Spring-created application context behind the PortalApplicationContextFacade, and this *just doesn't work* outside the context of a running uPortal in a servlet container. Let's get firm about that: that what we're writing is objects and services that run in a running portal, and anything else (Ant tasks?) doesn't belong in the same source tree and can't use these services that legitimately only exist in a running portal except by remoting to the portal. And then go after building and wiring and configuring the services that those components will use -- I don't object to their existing, but it's a serious problem that they basically "happen to work" in the current implementation based on classpath magic and rdbm.properties happening to be in the right place. So, concretely, if you declare a Spring bean that depends on JNDI, and an ant task runs and touches something that touches the PortalApplicationContextFacade, it blows up because the JNDI lookup fails outside the context of the portal running in a container. Which exposes a deeper design problem of running portals and outside the portal tasks trying to use the same services and configuration. A recipe for complexity.
So we drop the requirement of running outside a servlet container. We re-approach those problems and come up with things that intentionally work outside the container, either by having their own configuration or their remoting to a live portal or their using services explicitly designed for that context or whatever it's going to be. Write the uPortal-user-provisioning-tool-as-Eclipse-plugin. But if it touches PersonDirectory, have it do so be deliberately and be very sure how that is going to be configured is worked out.
In the servlet container, we embrace being in the servlet container. Install and rely on that context listener from Spring.
Okay. That was step two.
But we really need to get to step three, which is not only using the Spring context listener, but also using Spring WebMVC. Slam everything we got into a couple controllers, fine. But open up that potential for adding more parallel controllers, for starting to use Spring WebMVC error handling, slapping interceptors and aspects in.
Peter's rendering pipeline plugability and so forth for uP3 is great. But I want it crunched into a Spring controller.
Now I'm out of steps and just observing:
Firstly, uPortal's channel manager really wants to be a Spring bean container. ChannelToBeanProxy is cute and I'm convinced it's useful, but I think it just exposes a deeper realization that ChannelManager should be implemented in terms of a bean container. Channels are beans. The get their configuration wired in. But get them from a bean container that's able to differentiate prototypes from singletons and wire in richer dependencies and apply aspects and so forth. What we've proven with all those static factories and portal.properties properties is that we need to configurably wire services into channels.
Has anyone written the RBDMS-backed bean container?
Second, as cool as it is to wire services into channels, wouldn't you much rather be writing a portlet and use Spring PortletMVC? Wiring dependencies into channels only gets you so far, you're still stuck with the lack of compelling MVC framework and pluggable view technologies for channels. So we keep reinventing it. CWebmail has IXmlMethod. Other channels do other things. Over and over we re-implement grabbing parameters from static data and runtime data. I've kicked around the idea of writing Spring uPortalChannelMvc, which would look a whole lot like Spring PortletMVC except work for channels, binding runtime data to command objects, doing the validation thing, bringing in pluggable vie technology. My thought was that it would be great fun and ultimately low value because I should just give up and write Spring PortletMVC portlets.
The most important, transformative feature of uPortal 3 is pervasive Springiness, and while you can be better or worse at teasing out those extension points and defining good interfaces, more or less you can't help but produce a pluggable architecture if you use Spring properly, and it is this sustainably pluggable architecture that will be the single greatest contribution of uPortal 3. Let's really go after open-closed in the context of uPortal the way Scott has in CAS.
JSR-168 and JSR-286 are uninteresting from the perspective of JA-SIG. They don't matter. Don't go write a JSR-168, and don't worry about what features will be in JSR-286. These standards are the necessary evil that makes frameworks like Spring PortletMVC possible, and once that's possible, the productive thing is to jump on that. What we should all be doing is taking a look at Eric's Bookmarks portlet, articulating what extension points it needs to be an asset to MyRutgers, to Academus, to MyWisc. And then going after the open-closed core that works for everyone and local plugins that make us happy. And that's all about Spring PortletMVC and a domain model and good interfaces, and has very little to do with JSR-168.
JSR-168 is better than IChannel because it gets you to Spring PortletMVC. JSR-286 will be valuable only inasmuch as it allows SpringPortletMVC to be better. I'm interested in what I can do with PortletMVC and the opportunities it gives us to share controllers. I'm not interested in 286 for its own sake since the most productive thing to do is to jump on the PortletMVC framework.
I see the value of injecting spring resources into IChannels as allowing incremental decoupling and Springification of channels, allowing you to demonstrate incremental value or at least progress. The natural outcome is an eventual realization that all that's left in the channel is controllerish stuff, that all the services and domain have been extracted. But then the next step is to move the service and domain into a Spring PortletMVC portlet and re-implement the controller in that richer environment, continuing to realize incremental value in terms of not being forced to use XSLT as the view layer, etc. etc.
I've been playing with using your PortalApplicationContextFacade to acquire Singleton Beanfactory references to acquire Spring Managed beans implementing middle tier operations into my channels. Thoughts?
It's an approach. Channels are tightly coupled to uPortal anyway, so being tightly coupled to the context façade and looking up magic beans by name isn't the end of the world. This approach has the advantage of feeling a lot like our crufty static services invocation approach to life -- the Lookup (anti-)pattern.
Is there a better way?
I'm very attracted to going a step further and using ChannelToBeanProxy where the proxy IChannel looks up a named IChannel bean from the PortalApplicationContextFacade. Then you can wire in your Spring-managed beans to the channel, potentially wire in different service realizations or different proxies on top of services into different channels, etc. Gets a little closer to dependency injection.
Whether you inject into a Spring-managed IChannel instance or you write an IChannel that looks up the beanfactory and beans it needs probably isn't that different, though.
I've been digging for a way to get a startup contextListener to bootstrap the singleton beanfactory and maybe use the factory facilities to have it manufacture beans from the same context in both Spring managed and static contexts, but just thinking about it is so ugly...
It's not that ugly, and we really need to get there. Step one was what we did. Next step is to really buy Spring, use a Spring-provided context listener to bootstrap, and then use a uPortal-provided secondary context listener to expose that Spring-created application context behind the PortalApplicationContextFacade, and this *just doesn't work* outside the context of a running uPortal in a servlet container. Let's get firm about that: that what we're writing is objects and services that run in a running portal, and anything else (Ant tasks?) doesn't belong in the same source tree and can't use these services that legitimately only exist in a running portal except by remoting to the portal. And then go after building and wiring and configuring the services that those components will use -- I don't object to their existing, but it's a serious problem that they basically "happen to work" in the current implementation based on classpath magic and rdbm.properties happening to be in the right place. So, concretely, if you declare a Spring bean that depends on JNDI, and an ant task runs and touches something that touches the PortalApplicationContextFacade, it blows up because the JNDI lookup fails outside the context of the portal running in a container. Which exposes a deeper design problem of running portals and outside the portal tasks trying to use the same services and configuration. A recipe for complexity.
So we drop the requirement of running outside a servlet container. We re-approach those problems and come up with things that intentionally work outside the container, either by having their own configuration or their remoting to a live portal or their using services explicitly designed for that context or whatever it's going to be. Write the uPortal-user-provisioning-tool-as-Eclipse-plugin. But if it touches PersonDirectory, have it do so be deliberately and be very sure how that is going to be configured is worked out.
In the servlet container, we embrace being in the servlet container. Install and rely on that context listener from Spring.
Okay. That was step two.
But we really need to get to step three, which is not only using the Spring context listener, but also using Spring WebMVC. Slam everything we got into a couple controllers, fine. But open up that potential for adding more parallel controllers, for starting to use Spring WebMVC error handling, slapping interceptors and aspects in.
Peter's rendering pipeline plugability and so forth for uP3 is great. But I want it crunched into a Spring controller.
Now I'm out of steps and just observing:
Firstly, uPortal's channel manager really wants to be a Spring bean container. ChannelToBeanProxy is cute and I'm convinced it's useful, but I think it just exposes a deeper realization that ChannelManager should be implemented in terms of a bean container. Channels are beans. The get their configuration wired in. But get them from a bean container that's able to differentiate prototypes from singletons and wire in richer dependencies and apply aspects and so forth. What we've proven with all those static factories and portal.properties properties is that we need to configurably wire services into channels.
Has anyone written the RBDMS-backed bean container?
Second, as cool as it is to wire services into channels, wouldn't you much rather be writing a portlet and use Spring PortletMVC? Wiring dependencies into channels only gets you so far, you're still stuck with the lack of compelling MVC framework and pluggable view technologies for channels. So we keep reinventing it. CWebmail has IXmlMethod. Other channels do other things. Over and over we re-implement grabbing parameters from static data and runtime data. I've kicked around the idea of writing Spring uPortalChannelMvc, which would look a whole lot like Spring PortletMVC except work for channels, binding runtime data to command objects, doing the validation thing, bringing in pluggable vie technology. My thought was that it would be great fun and ultimately low value because I should just give up and write Spring PortletMVC portlets.
The most important, transformative feature of uPortal 3 is pervasive Springiness, and while you can be better or worse at teasing out those extension points and defining good interfaces, more or less you can't help but produce a pluggable architecture if you use Spring properly, and it is this sustainably pluggable architecture that will be the single greatest contribution of uPortal 3. Let's really go after open-closed in the context of uPortal the way Scott has in CAS.
JSR-168 and JSR-286 are uninteresting from the perspective of JA-SIG. They don't matter. Don't go write a JSR-168, and don't worry about what features will be in JSR-286. These standards are the necessary evil that makes frameworks like Spring PortletMVC possible, and once that's possible, the productive thing is to jump on that. What we should all be doing is taking a look at Eric's Bookmarks portlet, articulating what extension points it needs to be an asset to MyRutgers, to Academus, to MyWisc. And then going after the open-closed core that works for everyone and local plugins that make us happy. And that's all about Spring PortletMVC and a domain model and good interfaces, and has very little to do with JSR-168.
JSR-168 is better than IChannel because it gets you to Spring PortletMVC. JSR-286 will be valuable only inasmuch as it allows SpringPortletMVC to be better. I'm interested in what I can do with PortletMVC and the opportunities it gives us to share controllers. I'm not interested in 286 for its own sake since the most productive thing to do is to jump on the PortletMVC framework.
I see the value of injecting spring resources into IChannels as allowing incremental decoupling and Springification of channels, allowing you to demonstrate incremental value or at least progress. The natural outcome is an eventual realization that all that's left in the channel is controllerish stuff, that all the services and domain have been extracted. But then the next step is to move the service and domain into a Spring PortletMVC portlet and re-implement the controller in that richer environment, continuing to realize incremental value in terms of not being forced to use XSLT as the view layer, etc. etc.
Wednesday, June 21, 2006
Messy Desktop and the Ajax enabled portal
This video talks about organizing documents, but of course the same kinds of techniques can (and should) could be applied to interacting with portlets.
Getting beyond tabs and columns. Way beyond.
Getting beyond tabs and columns. Way beyond.
Tuesday, June 20, 2006
Re-using an existing web application as a Sakai tool
Another step closer to being able to drop in an existing web application as a Sakai tool. This feels a lot like uPortal's CWebProxy.
Tuesday, June 13, 2006
Wednesday, April 05, 2006
Too many ideas
Cleaing out my desk at Yale Technology & Planning, I came across some index cards of ideas we didn't get a chance to implement for YaleInfo. We used index cards taped to a door in priority order for project management some of the time. Pretty effective and concrete, with the ability to take a card, split cards, merge cards, hand cards -- a lot like Extreme Programming story cards.
Anyway, here are some of the cards I'm throwing out as a I tidy up and move on:
* Put sitemap in Guest header (theme stylesheet)
* Hover help for tabs
* Central backup channel
* Meeting maker basic channel
* most recent effors overall / error report
* ITS status with limit on number of items (display most recent 4 items) (implement by adding max feature to RSS)
* How to maintain Yale College Calendar channel
* Test DC on https URLs
* OPA wsbapp event feeds
Anyway, here are some of the cards I'm throwing out as a I tidy up and move on:
* Put sitemap in Guest header (theme stylesheet)
* Hover help for tabs
* Central backup channel
* Meeting maker basic channel
* most recent effors overall / error report
* ITS status with limit on number of items (display most recent 4 items) (implement by adding max feature to RSS)
* How to maintain Yale College Calendar channel
* Test DC on https URLs
* OPA wsbapp event feeds
Friday, March 31, 2006
uPortal 4 now available
uPortal 4 is now available. It is a flexible framework for developing your institution's portal. This is the most flexible version of uPortal yet, overcoming the limitations of coding to particular APIs and adopting particular libraries to deliver maximum options to the implementor. Continuing with the best practice of using external libraries rather than inventing new code, uPortal 4 has less custom code than any prior version. In keeping with the best practice of loose coupling, no uPortal-specific code in uPortal 4 is coded to concrete classes.
For a powerful, loosely coupled, infinitely flexible portal framework, look no further than uPortal 4.
(Happy April Fool's).
For a powerful, loosely coupled, infinitely flexible portal framework, look no further than uPortal 4.
(Happy April Fool's).
Thursday, March 16, 2006
Yale Technology & Planning Jobs
Yale University ITS Technology & Planning has two -- count 'em two! -- openings listed. Technology & Planning is a great place to work -- awesome coworkers, good working environment, neat projects. Be interested in these jobs.
Systems Programmer I Requisition #: CCRF33463
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 24 Duration: REGULAR - 12 MONTHS
Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue
Job Description:
General Purpose
Work with a small focused senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties of Position
1. Work in a collaborative fashion with a broad range of IT professionals to establish both needs and opportunities for emerging technologies.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
4. Produce technical white papers and presentations for consumption within Yale's ITS organization and at national conferences.
Education and Experience
1. Bachelor's degree or equivalent experience as well as a minimum of two years experience developing software in Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies.
3. Documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.
Skills and Abilities
1. Demonstrated track record of inquisitive self-direction and the ability to learn new things rapidly and completely.
2. Familiarity with the basic principles of relational database design.
3. Experience with at least one other high level programming language is desireable but not required.
4. Technical familiarity with one of the following operations systems is additionally desireable: Unix/Linux, Microsoft NT/XP, Mac OSX
5. Excellent written and verbal abilities.
Systems Programmer III Requisition #: CCRF33464
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 26 Duration: REGULAR - 12 MONTHS
Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue
Job Description:
General Purpose
Take a technical leadership position working with a small focused staff of senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties
1. Facilitate and lead in collaborative fashion projects involving a broad range of requirements as well as customers.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Work with the University IT leadership to establish goals and directions for foundation technology that serve us into the future.
4. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
5. Produce technical white papers and presentations for consumption both within Yale's ITS organization and at national conferences.
Experience and Training
1. Bachelors degree or equivalent experience as well as a minimum of 6 years experience developing software in the Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies as well as a concrete and demonstrated ability to evaluate, adopt and fully understand complex software frameworks and architectures.
3. Experience with at least one other high level programming language
4. Experience with the management, performance characteristics and basic principles of operation either Unix/Linux or Microsoft's NP or XP operating environment.
5. Familiarity and practical experience with project planning approaches and the ability to budget both temporal and fiscal resources.
6. A documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.
Skills and Abilities
1. Demonstrated ability to lead a technical team effectively.
2. Complete understanding of relational database principles and design.
3. Excellent written and verbal communications skills.
4 Demonstrated track record of successfully identifying, promoting and deploying products and services that represent long term value to their employer as well as providing bedrock technology upon which additional services are built.
Systems Programmer I Requisition #: CCRF33463
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 24 Duration: REGULAR - 12 MONTHS
Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue
Job Description:
General Purpose
Work with a small focused senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties of Position
1. Work in a collaborative fashion with a broad range of IT professionals to establish both needs and opportunities for emerging technologies.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
4. Produce technical white papers and presentations for consumption within Yale's ITS organization and at national conferences.
Education and Experience
1. Bachelor's degree or equivalent experience as well as a minimum of two years experience developing software in Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies.
3. Documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.
Skills and Abilities
1. Demonstrated track record of inquisitive self-direction and the ability to learn new things rapidly and completely.
2. Familiarity with the basic principles of relational database design.
3. Experience with at least one other high level programming language is desireable but not required.
4. Technical familiarity with one of the following operations systems is additionally desireable: Unix/Linux, Microsoft NT/XP, Mac OSX
5. Excellent written and verbal abilities.
Systems Programmer III Requisition #: CCRF33464
Posting Date: 3/15/06
Department: ITS Technology & Planning Work Site: 175 Whitney Avenue
Salary Grade: 26 Duration: REGULAR - 12 MONTHS
Schedule/shift: Full Time - 37.5 HRS; Weekdays 8:30-5:00
Internal applicants send bids to: Corey Rossman, 155 Whitney Avenue
Job Description:
General Purpose
Take a technical leadership position working with a small focused staff of senior ITS professionals that develop strategic technical directions for the University and explore emerging technologies.
Essential Duties
1. Facilitate and lead in collaborative fashion projects involving a broad range of requirements as well as customers.
2. Participate in large scale multi-University development efforts that utilize a fluid mix of both new and legacy development methodologies and technologies.
3. Work with the University IT leadership to establish goals and directions for foundation technology that serve us into the future.
4. Track and evaluate emerging technologies in fields that include (but are not limited to) software development languages and environments, network, information security and telephony.
5. Produce technical white papers and presentations for consumption both within Yale's ITS organization and at national conferences.
Experience and Training
1. Bachelors degree or equivalent experience as well as a minimum of 6 years experience developing software in the Java programming language.
2. Experience developing middle-tier applications utilizing Java Servlet/JSP technology. This experience should include familiarity with current design and coding approaches and methodologies as well as a concrete and demonstrated ability to evaluate, adopt and fully understand complex software frameworks and architectures.
3. Experience with at least one other high level programming language
4. Experience with the management, performance characteristics and basic principles of operation either Unix/Linux or Microsoft's NP or XP operating environment.
5. Familiarity and practical experience with project planning approaches and the ability to budget both temporal and fiscal resources.
6. A documented record of software development experience in either a corporate or university setting is necessary. Code samples may be requested and reviewed with the candidate.
Skills and Abilities
1. Demonstrated ability to lead a technical team effectively.
2. Complete understanding of relational database principles and design.
3. Excellent written and verbal communications skills.
4 Demonstrated track record of successfully identifying, promoting and deploying products and services that represent long term value to their employer as well as providing bedrock technology upon which additional services are built.
Friday, March 03, 2006
Wednesday, March 01, 2006
On Walled Gardens
The first issue is whether there is justification to try to reimplement an “educational” version of software when a perfectly good and popular generic version already exists.
It's important to be cautious of walled gardens. On the one hand there is the value of building a component in a tighter knit community where it can be more easily steered to meet very specific needs of the community and where the bandwidth of collaboration is limited to a manageable level. On the other hand there is the value of wider collaboration and thereby drawing a larger pool of contributions and interest.
As Michael Feldstein notes in his blog, there are times when higher education has unique needs and something to contribute by going after a need in a by, for, and about higher education way.
I worry too much. Lately, I've been worrying about two things in JA-SIG and uPortal. One of them is going after non-higher-ed-specific concerns in the context of JA-SIG. Yes, uPortal should have an awesome syndicated feed reader JSR-168 portlet. However, every other JSR-168-supporting portal on the planet has exactly this same need. There's nothing higher-education-specific about a syndicated feed reader. Therefore, the way to get the most participation, mindshare, involvement, etc., for such a portlet is outside the context of JA-SIG, is it not? Would it not be best to fork a SourceForge, Java.NET, JavaForge, etc. project wherein interested uPortal, LifeRay, JetSpeed 2, StringBeans, and other portal deployers with this need can collaborate on a single excellent syndicated feed reader portlet for use in all these portals? Or on several of them. There may be be room for several syndicated feed readers with different feature sets, but I don't think their adopters will be neatly partitioned by portal platform or even by higher ed vs. commercial. There are opportunities here.
Another worry is not going after higher-education-specific concerns in the context of JA-SIG. Java really is an architecture that can be used effectively in the administration of higher education. We've got to have some shared needs that are higher-education-administration but not pedogogical tools (teaching tools intended for use in the context of particular courses are likely most appropriately implemented as Sakai tools). What are they, and how to can we effectively pursue them in the context of JA-SIG to everyone's benefit?
Subscribe to:
Posts (Atom)
