Menu
▾
▴
Re: [WWdevel] javaScript addins
|
From: Michael G. <ga...@ma...> - 2010-06-18 14:10:58
|
Hi Djun, On Jun 16, 2010, at 5:20 PM, Djun Kim wrote: > Hi Michael - > > thanks! I'm excited to hear about all of the work that's going on. > > On 2010-06-15, at 4:57 AM, Michael Gage wrote: > >> Hi Djun, >> >> I have added the tool-tips to the Answer previews in the HEAD version of WeBWorK using >> the Walter Zorn tooltips javaScript library. If you hover the mouse over the Answer previews you >> now get a tooltip with the original entry string which you can copy and paste back in to answer blanks. >> >> This means that we can remove the "entered" field in the answer analysis which would save us some room. >> I haven't done this yet. Undoubtedly the tool tips can use some tweaks in terms of color/appearance and perhaps >> placement. See what you think. >> >> One thing that I forgot to mention in the list I sent you last week is that the template and css files that define >> the look and feel of WeBWorK (and the placement of the content on the page) are quite flexible >> but not greatly utilized -- only a few people have done more than swap the color schemes on the pages. >> >> One reason for this is that we have no documents on the WeBWorK wiki about how to make CSS and template changes nor examples >> of how schools have customized the look of WeBWorK to the needs at their school. A relatively small project >> which would increase this flexibility even more would be to rewrite the Problem.pm module, separating out function >> and presentation more than is done at present, and outputting the rendered text in a more modularized way so that >> it can be rearranged merely by changing the template. > > Great - I was wondering about the way things were done, for example, why the template files and css files live in > different directories. I was thinking it might be nice to have all 'theme' related files in their own directory for ease of > packaging. Not sure what impact this might have on people who are serving static files via a separate server, > though. Anyway, something to think about... > True enough -- I think the original rational was that the active .css file is directly accessible from the web while the system.template file is not. So template.system was in the conf directory, while the css file had to be under webwork2/htdocs or else linked to something in there. The original rational again was that anything webaccessible had to go through either webwork2/htdocs or course/html -- it was a very primitive form of taint checking. I'm open to other suggestions for organization -- although we will also have to deal with the migration issue if we come up with a better idea. >> >> I will be meeting with our IT folks the week of June 28 and our goal is to finish our version of the Blackboard/WeBWorK connection. >> Hopefully by the end of that week I'll have good news about how that works and may be able to show you something at least >> slightly portable. > > Great! > >> >> We're within a week or so of switching over from the cvs to the svn -- Jason Aubrey has been setting this up. There are some documents >> up on the web already at http://wwrk.maa.org/wiki/Subversion. We will keep the cvs as a read only repository for the foreseeable future. > > Super... I'd started to import the CVS history into a git repository for local work, but SVN should make life much easier for lots of people. The svn docs are at -- http://wwrk.maa.org/wiki/Subversion Email Jason Aubrey <au...@ma...> for permission to commit to the svn. We were thinking that you might like to keep some of your more stable development in something like ......svn/system/branches/djun_project/webwork2 and coordinate with us about when and if to merge that code into the main development trunk. >> >> >> While adding the tooltip feature I came across another javascript library that looked interesting: extjs at www.extjs.com >> Are you familiar with it? It looked like it could be used to spruce up the instructor pages -- particularly the tables for dealing with >> homework sets and with maintaining classlists. > > I'll take a look - I'm a big fan of jQuery as a JavaScript framework, but this looks interesting. Looks like a dual-license model, > supportive of open projects. My son David (a recent CS graduate) introduced me to jQuery -- he just programmed a graphicsInput device in html5 using jQuery a little and processing.js a good deal more. A prototype is at https://hosted2.webwork.rochester.edu/webwork2/dgage_course/graphInput/4/ (you can login as guest) I have to do some more work to connect it up to some sample problems. It looks like HTML5 will be a lot lighter weight than either the java applets or the flash applets we have been using earlier. Talk to you later. Take care, Mike > > More soon, > > Djun >> >> Take care, >> >> Mike >> >> >> >> >> On Jun 12, 2010, at 11:32 AM, Michael Gage wrote: >> >>> Hi Djun, >>> >>> This sounds like very interesting work that you have been doing. >>> Working on the UI is particularly helpful since the last time we had someone >>> working full time on user interface issues was probably 5 or 6 years ago >>> when Robert Van Dam ( a student at Rochester, then went to BYU for graduate >>> school and is now gainfully employed (I hope :-) ) ) constructed the >>> instructor interface. The technology has advanced enormously since then. >>> At the time we avoided javaScript as much as possible since not every browser >>> could handle it and every browser did it differently. Now, with the exception of the >>> older MSIE browsers, javaScript has become pretty standardized and very useful and >>> it's past time that WeBWorK was updated to take advantage of it. >>> >>> The user interface balancing parens will be particularly useful for students. >>> >>> A. On the problem editing page I have several comments: >>> 1. Judging from the picture on your blog you are using the PGProblemEditor from the rel-2-4-patches >>> release. You might want to update to the HEAD release for your additions >>> (use cvs update -dAP >>> to remove all sticky tags, get the latest versions of the files and allow new directories to be build if needed.) >>> >>> I made several minor improvements to the editor "save" interface that made it easier for me to create new questions. >>> Of course there is much more that could be done with this user interface. I've been focusing on getting >>> better access to the language documentation. If your CodeMirror package has auto-completion facilities >>> that would be a very interesting addition. >>> >>> 2. Are you aware of the firefox plugin "It's all text"? Using that, or something similar, you can export a text area region >>> to your favorite editor (I'm on a mac most of the time so I have been using BBedit), edit the code there (where syntax highlighting >>> is available) and then saving back to the text area. It makes save a two step process but it works well enough that I didn't >>> feel too much pressure to upgrade the problem editor for my own personal use. >>> >>> 3. A few weeks ago I did reorganize and upgrade a commandline stand alone editor which uses the webservice feature of >>> the editor. It's in /webwork2/clients/renderProblem.pl (the HEAD version) with a support file at /webwork2/lib/WebworkClient.pm. >>> As it stands it is pointed at the hosted2.webwork.rochester.edu site, for rendering the problem, but you could point it at any site >>> running the HEAD version. The common code in WebworkClient.pm is used in the client renderProblem.pl and also in a web >>> version of the client defined at lib/WeBWorK/ContentGenerator/renderViaXMLRPC.pm. >>> >>> Basically renderProblem.pm takes a WeBWorK question text from STDIN on the command line, sends it to be rendered and then >>> fires up a local browser to read the result. I use it as a filter on BBedit to immediately render a problem I am working on. >>> >>> You'll want to look at the first couple of lines of code in renderProblem.pl since there a few constants that will need to be set for your >>> environment. There isn't much documentation yet and there are probably still a few tweaks that will make it easier to install >>> and use. Let me know how it works for you. >>> >>> B. As to including your additions into the main WeBWorK code repository. We're more than delighted to do this. We are, as I write this, in the >>> process of switching over from the CVS repository system at U. of Rochester to using an SVN system installed on the servers at >>> MAA. Jason Aubrey at U. of Missouri has been leading this. I have a local svn version checked out and it seems to be working well so far. >>> I think that next week we will be writing HOWTO documents for developers to start using the SVN system and if you are willing >>> you can be one of our first test cases. I've been quite satisfied with CVS for the clients and anonymous downloads but it can be >>> a bit clumsy keeping both production and development versions organized and constructing new releases. We did a lot of >>> backporting by hand. I'm hoping we can learn to use SVN more efficiently. I looked at GIT a few years ago, but it while it seemed really >>> excellent for development -- one of it's strong points seemed to be that there are multiple repositories which are easily shared. Since >>> one point of the repository at MAA is to keep an authoritative version of WeBWorK available for those who are not particularly adventurous >>> we've gone with SVN for now at least. Jason has been able to make it integrate well with mediaWiki and should be completing the process this week. >>> >>> C. The question of how to maintain a question library (NationaProblemLibrary) is still pretty much up in the air. It could be that >>> a GIT repository system might be more appropriate for that since the balance between having a central repository and being able >>> to produce and share created problems is quite different for questions, and even for macro files, than it is for the core WeBWorK >>> code. I'd be interested in your ideas on this -- I certainly have a lot to learn about the various ways of managing code. The bigger >>> problem with the question library is on the social organization side -- how do we get questions edited, rated, advertised, coordinated >>> with textbooks, metadata added and maintained and so forth. >>> >>> D. Back to the UI for instructors and the possibilities of AJAX type upgrades. I think the Library Browser (and the Homework detail editor) page >>> might benefit particularly from this. Make a page where one could display the contents of the library more easily (at the very least use >>> a widget to make the drop down menu for the NPL directory hierarchical ). Ideally one should be able to drag and drop library questions from >>> one panel into a second panel which is your homework set. You should also be able to drag and drop to rearrange the >>> order of homework problems in your homework set. (Homework set detail was close to state of the art when it was written, many years ago, >>> but the tools available have changed enormously.) This is not a small project, but it's isolated from much of the rest of WeBWorK code. >>> >>> E. Another UI feature, which I have researched some, but not gotten started on, is to add tooltips to the equations -- I have done the easiest thing using the title attribute-- >>> namely that if you look at Answer Preview for say the problem https://hosted2.webwork.rochester.edu/webwork2/maa104/Demo/3/ >>> and hover over the typeset answer, you'll see the original string that was entered. (This means we don't need the "entered" box -- it isn't much >>> used anyway since the answers are sticky in the answer blanks.) I could do the same with "Correct Answer" -- namely print the >>> typeset version to the screen and have a tooltip for the TI83 entry code, however instructors often want to copy the "Correct Answer" >>> and place it into the answer blank to test a problem -- this can't be done using the simple "tooltip" created by using the title attribute (as far as I can tell) >>> However -- there are more extensive tooltip libraries available that would allow one to do something like: have all formulas on the screen be typeset -- >>> by hovering over one you get a tooltip representation of the input code -- you can copy that code representation for use in pasting into an >>> answer blank. My quick research into the subject seemed to indicate that the tooltip library created by Walter Zorn (his site seems to be off >>> the air but I found a cache of it at http://web.archive.org/web/20080103025434/www.walterzorn.com/index.htm ) is among the best >>> and most widely respected. It might have other uses besides the one I described above. I haven't started studying it yet but >>> I will let you know if I do -- if you start working with it, or know of a better tooltip implementation please let me know so that we don't duplicate effort. >>> >>> F. Blackboard/Vista integration. If you haven't started on this yet, I suggest that you hold off for a few days. The local IT people at U of Rochester >>> hired a student, Martin Georgiev, to accomplish single sign on and gradebook integration between blackboard and WeBWorK -- similar to the integration I have working between Moodle and WeBWorK. They had a working development version but didn't get a production package created (and then the IT supervisor was called off to handle more immediate fires :-) ). I'll make inquiries this week and see if they have some free time over the summer-- I think we are within a few concentrated hours of having a working package that would connect Blackboard and WeBWorK. It might still require >>> further development, but you would have something substantial to start with. >>> >>> G. If you haven't looked at it yet you should look at the Moodle/WeBWorK integration (bridge1). For example: >>> http://hosted.webwork.rochester.edu/moodle/course/view.php?id=3 and the page: http://wwrk.maa.org/wiki/Moodle_Integration >>> for a description of both bridge1 (WeBWorK assignment type intoperation) and bridge2(question level interoperation). The latter >>> is in very rough beta -- but would allow those who are used to Moodle to push the WeBWorK interface entirely into the background. >>> It's worth completing. >>> The Moodle/WeBWork, Blackboard/WeBWorK bridges are the reason that I haven't worked too hard on interactive chat -- or bulletin boards >>> since those systems already have those available at one level or another and I don't want to reinvent wheels unless we can actually do it better. >>> >>> I haven't considered interfacing with Drupal (which I think of as a content management system, (CMS) not a course or learning management >>> system (CMS or LMS) -- it seems more like a version of mediaWiki which we have moved to for our central documentation. So far we've been >>> pretty happy with that. If you have specific ideas about what to do with a Drupal/WeBWorK integration I'd be interested to hear them. >>> >>> H. We have authorization via LDAP and a few other mechanisms but not via Shibboleth as far as I know. It would be a worthwhile >>> addition. >>> >>> I. I just uploaded some improvements to the WeBWorK admin page that make migration to new versions of WeBWorK easier -- basically it >>> allows you to do many upgrades to the course database tables from the Web rather than running dbUpgrade from the command line. >>> It also works better. :-) (It wouldn't be hard to attach a command line front end to the upgrade mechanisms for those who prefer that.) >>> Having said that -- anything that makes installation and management easier would be very welcome! >>> >>> J. One big project -- one that takes some planning -- is to redesign the WeBWorK database. Historically WeBWorK started using >>> GDBM database (msql, mysql's precursor had just started and was still too slow to use when we began Webwork -- we couldn't and can't afford Oracle :-) ) >>> Even when we switched to mysql around 2000 or 2001 we maintained backward compatibility --- the result is that each course has >>> a dozen tables attached to it. One of our students, Matt Leventi, now at Microsoft, explained to us why this was not the best solution. >>> We'd like to change the structure dramatically -- so that it is more like Moodle's. Roughly speaking it's a matter of transposing the >>> matrix, and also of breaking up some of the longer tables and using LeftJoins to retrieve the data. First of all this means >>> that instead of adding a dozen tables every time you added a course you would have a fixed number of tables and adding >>> a course would merely add lines to those tables. This would be much easier to maintain. Not much more has been done although >>> Jason and I have discussed the possibility of organizing a video conference on this theme in order to start gathering ideas about what >>> the new database should look like. >>> >>> Thanks for joining in on the WeBWorK project. It's also given me an opportunity to organize my own thoughts on what needs to be done next. >>> I look forward to adding your contributions into the main code. Let me know if you have any questions or suggestions and please keep >>> us informed of any projects you start up so that we don't duplicate effort any more than necessary. >>> >>> Take care, >>> >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> >>> On Jun 11, 2010, at 6:55 PM, Djun Kim wrote: >>> >>>> Hi Michael, >>>> >>>> Thanks for getting back to me! >>>> >>>> On 2010-06-07, at 6:24 PM, Michael Gage wrote: >>>> >>>>> Hi Djun, >>>>> >>>>> Welcome. >>>>> >>>>> Pardon the delay in replying -- I've been out of town for a few days and am still catching up on the email. >>>>> >>>>> We are delighted to have help at any level -- help with documentation, help with writing math problems, >>>>> help with new PG macros for making writing problems easier (macros as in TeX macros that make LaTeX more friendly than TeX), >>>>> or if you like working with perl -- help on the core code base -- from instructor/user interface improvements to hidden database improvements. >>>>> >>>>> So for me the first order of business is to find out what you are interested in, more precisely and what skills you have. >>>>> For you. If you haven't checked out the information on our wiki at http://webwork.maa.org you should do that -- and join so that you >>>>> have access to post on the forums and can edit the wiki. >>>> >>>> We're pretty excited about WeBWorK here at UBC. I applied for a small grant to do a little bit of development, and it looks >>>> like there's quite a bit of interest in supporting additional work. >>>> >>>> The initial work I've been doing is focused on two areas: UI/UX improvements, and interoperability. >>>> >>>> UI/UX: I've integrated CodeMirror code editor widgets into the WeBWorK student answer screens and the Problem Editing screen. >>>> This provides (e.g.) syntax highlighting and parenthesis matching. I'm currently working on a little bit of general UI cleanup - I'm thinking I'll restrict myself to CSS tweaks + JavaScript helpers to start with. Next up on the UI/UX front is a bit of an experiment: integration with a jabber-based >>>> chat client to support on-line interactive tutorial help. >>>> >>>> I've written a little bit about what I've done so far on my blog at http://teaching.puregin.org/blog/djun-kim/ui-improvements-for-webwork, >>>> with a couple of before and after screenshots. >>>> >>>> Interoperability: planned work: allow authentication via Shibboleth. Grade exports to Vista/Blackboard. Integration with >>>> our Student information systems (unlikely to be very universal/portable). >>>> >>>> So far this work is all been pretty preliminary, but in the next few days (once I get my git repository whipped into better shap) I'll have a demo site available and some code for your review and consideration. >>>> >>>> I see the following as the main strengths of WeBWorK at this point: >>>> >>>> * large base of users; community >>>> * large, public problem libraries >>>> >>>> I'm interested in: >>>> >>>> * lowering barriers to authoring and sharing problems >>>> * improving UX for learners - expanding interaction modes >>>> * integration with Drupal >>>> * making installation / mass hosting easier >>>> * providing evaluation of answers via Macsyma, as an option >>>> >>>> >>>>> >>>>> We're happy to have new comer edits on the wiki -- because there are many things confusing to newbies that the old timers >>>>> don't even notice -- having come to terms with the confusion long ago. >>>> >>>> I've certainly been reading through and learning from the wiki - I'll sign up and contribute some of my notes as I learn more about >>>> the code. >>>> >>>>> >>>>> Hope to hear more from you soon. >>>>> >>>>> Take care, >>>>> >>>>> Mike >>>> >>>> Best regards - looking forward to hearing from you. >>>> >>>> Djun >>>> >>>>> >>>>> On Jun 4, 2010, at 5:57 PM, Djun Kim wrote: >>>>> >>>>>> Hi All >>>>>> >>>>>> I'm interested in doing some development on WeBWorK. >>>>>> I wanted to introduce myself and get some sense for what >>>>>> activity is currently happening with the project. >>>>>> >>>>>> Cheers, Djun >>>>>> >>>>>> >>>>>> ------ >>>>>> Djun Kim, Ph.D. >>>>>> UBC Skylight Research Associate / Mathematics >>>>>> >>>>>> dju...@ma... >>>>>> Tel: (604) 822-0683 >>>>>> Office: Math 238 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>>>>> lucky parental unit. See the prize list and enter to win: >>>>>> http://p.sf.net/sfu/thinkgeek-promo >>>>>> _______________________________________________ >>>>>> OpenWeBWorK-Devel mailing list >>>>>> Ope...@li... >>>>>> https://lists.sf.net/lists/listinfo/openwebwork-devel >>>>>> >>>>> >>>>> >>>> >>>> ------ >>>> Djun Kim >>>> UBC Skylight Research Associate / Mathematics >>>> >>>> dju...@ma... >>>> Tel: (604) 822-0683 >>>> Office: Math 238 >>>> >>>> >>>> >>>> >>>> >>> >> > > ------ > Djun Kim > UBC Skylight Research Associate / Mathematics > > dju...@ma... > Tel: (604) 822-0683 > Office: Math 238 > > > > > |
