Forums | Mahara Community
News
/
Call for Case Studies, Roadmap, Project Update
17 April 2009, 7:11
Hi Jez,
Yes, the resume is definitely substandard, which is largely my fault, as I originally wrote it... but that had a lot to do with time pressure.
The ability to configure custom fields has been requested many times. It would be great to be able to configure different types of fields, whether they are 'composite' fields (eg the ones made up of many items like education history etc) or normal, what fields they have, with what types of data they expect.
However, the recent LEAP (import/export) work makes me realise that this has other impliciations. If you just let administrators define fields, then Mahara has no idea really what they actually *mean*, so when you come to exporting them, it gets into a bit of trouble trying to map them into a portfolio standard.
These are not insurmountable problems, of course, and like anything else in opensource, it's a matter of time and/or funding ;)
17 April 2009, 8:11
Hi Penny,
Sub Standard is a bit harsh, I think overall its very good, its just not very intuitive when it comes to the navigation!
I dont think I explained myself very well regards custom fields... what I was asking was whether we could add more standard fields to Mahara, for example "conferences attended" but have these enabled / disabled within the admin section... so... within admin see a list of possible fields with a check box to switch them on or off. So, we get more flexibility as instututions but we are still using standardised software / records. If we were able to change labels on those fields that would give even more flexibilty.
I know this starts to add complexity, but I think resume's are one area where insitutions needs (wants) will be more diverse.
Jez
17 April 2009, 8:47
Hi Jez, Penny
Not knowing (as Penny does so well) the innards of Mahara, I can allow myself the luxury of envisaging what might be possible, not knowing how difficult it would be to implement...
... I can imagine a "template CV" (or indeed a template report of any kind) composed of units that are specified by the provider's admin role. This could tie in nicely to the kind of vocabularies specified in LEAP2A. You might say, to specify one unit, "show all the activities categorised as Work in the last 10 years". Or "show all educational activities that lasted longer than 1 month, between 2 and 5 years ago, linked to this ability <uri>".
So I suppose it needs us to define a query language. Wouldn't it be nice to use something standard like SPARQL (at the back end, with a nice front end) which we could do if Mahara (or other system) adopted a common RDF model based on LEAP2? (Definitely on the cards.) OK, I'm talking to developers here, not practitioners, sorry Jez!
Best wishes
Simon
17 April 2009, 10:09
Are you (Simon) suggesting that the XML queries be added by admins to enable export / import?
So, if an admin adds a custom field, they have to add a custom query to handle its export?
To be honest I think something far simpler would do. Penny seems to be concerned about
"If you just let administrators define fields"
What I am suggesting is that Mahara.org define additional fields which can be re-labeled / shown / hidden. You know what they "mean" becuase you have defined them as being part of the resume. As long as configurable labels get exported / imported... they will go back into the resume with those labels and have "meaning" to the user... but also "meaning" to mahara as they are recognised as being a configurable / renameable field from the resume...
Does this make sense... essentially... add redundant show / hideable fields that admins can re-label. that is not the same as allowing admins to "create custom fields"... I do not think...
17 April 2009, 10:04
Ah well, thanks anyway, but it's not my most proud moment :)
I did understand what you were saying... but people have asked for more flexibility than that, and I think it's a good idea. We could also make it pluggable but then each resume sub-plugin would have to implement all the associated export formats .. and import formats, and it's a bit too heavy in my opinion.
Something like that which Simon suggests sounds good too!
- «Previous page
- 1
- 3
- 4
- »Next page