Date: Thu, 28 Mar 2024 12:16:07 -0400 (EDT) Message-ID: <462661995.28284.1711642567424@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28283_125396782.1711642567424" ------=_Part_28283_125396782.1711642567424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We will use the international conference call dial-in. Please follow dir= ections below.
DSpace 6 Testathon preparation: the ultimate repository manager test pla= n
Update on the UI Working Group
Is it desirable to have WYSIWIG editi= ng of metadata fields? Is it desirable to have rich text in metadata fields= at all? (XMLUI already supports MathJax notation for formulae in metadata = fields)
Review the DSpace Release = 6.0 Status pageUI Working G= roup
Gather existing DSpace testing scripts
We discussed the opportunities for DCAT to create a Standardized testing= script for the DSpace 6 Testathon. This script would be used by administra= tors testing the DSpace 6 release candidate. It therefor focusses on parts = that can be examined visually and thus are part of the User Interface. As D= Space 6 will not yet have a unified UI we will have to create two testing s= cripts, one for JSPUI and another one for XMLUI.
On the long term this testing script will have to become even more stand= ardized to use it for testing purpose on future DSpace versions.
At this moment there are several DSpace repository managers using their = own testing scripts for internal testing purpose. As those could contain ma= ny interesting points of view for a standardized testing script, these scri= pts can be used to start from. In case you would have your own testing scri= pt which you are wiling to share, please add a link to it in the comment se= ction below.
We will have to use two parallel documents. One for XMLUI and one for JS= PUI. It would be beneficial if those documents could contain scripts for di= fferent persona's. We could for example create a spreadsheet for each UI co= ntaining separate tabs for the persona's of DSpace admin, community admin, = collection admin and DSpace submitter. Each of those tabs would contain tes= ts tailored to the persona.
There are many tools available to collaborate in the creation of our tes= ting script. Some people mentioned google docs and google spreadsheets to b= e useful. Another way of dealing with multiple actors could be by creating = a wiki page.
To coordinate the creation of the testing script we will work on a wikip= age. We will collaborate on this page until October 13th, on which we would= need a first draft of the script to discuss during that day's DCAT meeting= . After the discussion we have until December 1st to process our remarks in= to a final version which will be used during the Testathon from December 1= st to 11th.
When the final version is ready a separate wiki page will be created lin= king to the test script and providing some additional information aimed at = repository managers willing to perform the tests.
The script itself could be published as a google spreadsheet or equivale= nt. Although the format is currently undecided it would be beneficial to ad= d a column for jira tickets. This column should not be mandatory however. T= esters feeling confident a certain issue deserves a jira ticket could creat= e one and link to it in the column. Others could note down their comment in= this column. Afterwards their remarks should be reviewed by another tester= who could still decide to create a jira ticket.
In the past testers were encouraged to a release candidate locally and p= erform the test on their own DSpace instance. To not only standardize the t= est itself, but also the environments on which they are performed, the test= s themselves should be done on the demo.dspace.org environment instead= of locally.
The creation of the testing plan will be coordinated by Amanda French, Kate Dohe & Bram Luyten (Atmire).= Others willing to join the task force could join anytime.
The UI working group is raising a call for designers who would come up w= ith a new User Interface design. Main idea of this design is admins to be a= ble to configure more in the user interface instead of in the configuration= files. The combination of future DSpace versions and the new UI should als= o make the whole more modular.