jjak0b / mandm Goto Github PK

Problema posto come da titolo, ma non dovrebbe mostrare le nuove attività della storia perchè importando una nuova storia il comportamento corretto dovrebbe essere di tornare nella sezione di MissionsEditor, perchè nessuna missione è stata selezionata.
Un comportamento alternativo potrebbe essere quello di selezionare in automatico la prima missione.

Come da titolo
Se con un certa lingua di creazione si è scelto un file tramite la sezione del form, cambiando successivamente la lingua, sulla sezione del form rimane il file quello precedente senza rimuoverlo.

Questo può portare all'utente a non capire che può aggiungere un altro file che verrà associato in automatico alla lingua selezionata

In particolare deve permettere di selezionare una funzione con un parametro.
Il parametro può essere creato a piacere dall'utente:

• singolo / costante
• Array,
  In entrambi i casi devono avere un tipo tra cui:
• Numero
• stringa
• data
• ora

Poichè l'autore potrà creare delle missioni con al loro interno attività che potrebbero portare ad attività diverse in base al tipo di scelta fatto o altro, stavo pensando che potrebbe essere utile strutturare le attività sotto forma di flowchart, quindi attività condizionali, e sequenziali ed eventualmente altre tipo un "goto" su un altro nodo ( per anche simulare l'iterazione ), o l'iterazione, stessa ma per non renderlo troppo complicato (non dobbiamo necessariamente renderlo turing completo), potrebbero bastare anche solo i primi 2 o 3 tipi .

Come titolo, certe opzioni del menu contestuale possono essere nascoste ed uno screen reader le annuncia anche se sono visualmente nascoste ma non nascoste o disabilitate con aria-disabled o aria-hidden

@iacop In riferimento a 269bbbf
Il drag and drop non ritorna il focus sull'albero o sul nodo selezionato dell'albero ( meglio quest'ultimo)
Inoltre mancano gli attributi

• aria-haspopup=true su tutti i nodi dell'albero;
• aria-grabbed=true sul nodo preso (grabbed) e false in tutti gli altri
• aria-dropeffect=<effetto> sul nodo selezionato di destinazione

Come da titolo, nell'editor, se si elimina una missione che era stata precedentemente aggiunta ad un gruppo, non viene correttamente rimossa dalla lista di missione associate a quel gruppo

Considerato che i contenuti dell'ambiente Player devono essere mostrati/eseguiti anche in modalità offline (o almeno dove possibile), è necessario che il player scarichi tutti gli assets dinamicamente scaricabili prima dell'avvio effettivo della storia.
Attualmente vi sono alcuni metodi
Quello che prenderei in considerazione, dato il peso significativo degli assets è

• Uso di blob indicizzati in IndexDB combinati a CacheStorage, come nell' esempio

Secondo la specifica WAI-ARIA

If the complete set of available nodes is not present in the DOM due to dynamic loading as the user moves focus in or scrolls the tree, each node has aria-level, aria-setsize, and aria-posinset specified.

aria-setsize e aria-posinset non sono specificati sul nodo di jstree

Nell'editor c'è la funzione changeSelector così definta:

changeSelectedStory( name ) {
   let story = this.localStories.find(function( story ) {
   	return story.name === name;
   });
   if (story) {
   	this.cache.story = story;
   	let self = this;
   	let getlocale;
   	Object.keys( this.cache.story.dependencies.locales ).forEach( locale => {
   		getlocale = self.$i18n.getLocaleMessage( locale );
   		getlocale.assets = {};
   		self.$i18n.setLocaleMessage( locale, getlocale );
   		self.$i18n.mergeLocaleMessage( locale, this.cache.story.dependencies.locales[locale] );
   	});
   }
},

@iacop Credo che la riga this.cache.story = story; dovrebbe stare alla fine e this.cache.story.dependencies.locales[locale] dovrebbe essere story.dependencies.locales[locale], perchè così semplicemente mi sembra di capire che rimetti e togli le stesse traduzioni nella stessa storia

Quando i nomi delle attività sono rinominate nell'activityEditor, il nome è aggiornato sia il sul nodo nell'albero e anche sul noteInfo.
Però se dopo aver salvato la missione/storia, si ricarica la storia, il nodo della corrispondente attività ha il nome precedente, ma in NoteInfo è rimasto salvato.
Sicuramente da questo commit c'è 0969248 ma probabilmente c'è anche da molto prima.

Considerato che l'aspettativa sul framework client-side da utilizzare è Vue, un particolare molto importante su cui decidere è se adottare a lato client un'architettura SPA (Single Page Application) o MPA (Multiple Page Application); Vue si presta molto bene all'approccio SPA, rimanendo comunque compatibile per quello MPA.

Non ho ancora preso decisione formale, ma per il momento tendo verso l'approccio SPA. Voi che decidete? Vantaggi della scelta SPA

• L'ambiente di utilizzo atteso dell'applicativo è un museo, dove la connettività (WiFi o rete mobile) potrebbe essere limitata. Una SPA limita il quantitativo di informazioni da scambiare tra client e server, riducendolo prevalentemente a messaggi JSON/XML
• La sensazione di utilizzo di una SPA da parte dell'utente è molto simile a quella che si ha nell'interfacciamento con app native, cosa molto gradita

è necessario sistemare la maggior parte degli errori o warning che compaiono in console
Nota: per abilitare la developer mode di Vue, dove sostituire il tag script di Vue in index.html con
<script crossorigin="anonymous" src="https://cdn.jsdelivr.net/npm/[email protected]/dist/vue.js"></script>
perchè la versione vue.min.js è implicitamente la production mode

Propongo di utilizzare la seguente struttura ad albero, per organizzarci durante il progetto

1. Ogni modulo o applicazione è implementato in una cartella separata.
2. Dentro ogni modulo, se può essere accessibile all'esterno sarà presente una cartella public e configurata opportunamente come statica su express, per rendere disponibili le risorse in tale locazione.
   a. Nota: Questo non vale però per i moduli o librerie importate esternamente, si deciderà in base al loro utilizzo
3. Nella cartella shared saranno aggiunti eventuali librerie di utility o condivise per vari motivi dalle varie applicazioni/moduli

• player
  • public
• editor
  • public
• evaluator
  • public
• shared
  • public
• liberie/moduli
  Non avendo esperienze con node ed express non so se questo "layout" può rivelarsi comodo in futuro, però in altri ambiti mi è sembrato comodo.

Penso sia tempo di prendere qualche decisione sul look-and-feel generale dell'applicazione. Trattandosi di un applicativo dalla forte componente mobile, punterei per qualcosa di analogo a quanto mostrato nella schermata

In altri termini

• Pannello laterale sinistro, accessibile dal tasto in alto a sinistra
• Banner centrale/menu bar in alto al centro e a comparsa, con eventuali tasti ad accesso rapido
• Varie ed eventuali da decidere in fase di prototipizzazione

Non sono molto ferrato in ambito di UX, quindi perdonate se non ho saputo esprimermi con il lessico appropriato. Quello che propongo è un abbozzo temporaneo, al quale eventualmente aggiungere o togliere cose. Siete d'accordo, avete proposte da fare? Va inoltre decisa la libreria/toolkit grafico con cui realizzare la parte grafica; ignorante come sono di queste cose, al momento l'unica scelta di cui dispongo è Bootstrap.

Il testo di questo issue è soggetto ad editing e riflette la decisione comune dei partecipanti.

Serve evidenziare in qualche modo all'utente quelle aree di I18nInputWidget che sono "dinamiche", in base alla lingua scelta.
Sicuramente una descrizione "tutorial" nella homepage dell'editor può aiutare, però pensavo anche ad un modo tramite decorazione CSS o con Bootstrap, e in aria tramite delle label o specifici attributi per segnalare che quel campo è dipendente dalla lingua e quindi "localizzato"

@iacop @Calispo Chiedo un attimo la vostra attenzione per discutere su questo problema.
Considerato che tramite UserWidgetEditorMediaPlayer, è possibile creare un widget multimediale contenente immagini, video, audio, didascalie/sottotitoli; Si deve rendere possibile il loro caricamento sul server.
Da qui in avanti. considero "risorsa" un qualsiasi file multimedia che ho elencato.
Ho pensato che ci potrebbero essere 2 approcci, 1 uno dei quali potremmo prendere in considerazione.

1. Approccio condiviso: le risorse sono condivise, cioè ogni risorsa può essere ri-utilizzata in altre storie tramite un path condiviso (es: assets/videos/nyancat.mp4).

   • Pro:
     1. Potenzialmente non esisterebbero duplicati
     2. In fase di duplicazione della storia non ci sarebbero conflitti di link, perchè verrebbe copiato un link condiviso di ogni risorsa nelle storie
   • Contro:
     1. Cosa facciamo nel caso la risorsa sia eliminata ed è utilizzata in varie storie ?
     2. Richiede implementazione di un "Assets manager" nel editor

2. Approccio "standalone": ogni storia è indipendente dalle altre, quindi ogni risorsa è presente nel path della storia, o comunque è logicamente dipendete dall storia (es: stories/xxxxx/videos/nyancat.mp4)

   • Pro:
     1. "facile implementazione" ma in realtà avremo a che fare con i contro
   • Contro:
     1. In fase di duplicazione serve stare attenti ai link delle risorse utilizzate ... Cosa facciamo in fase di duplicazione ? duplicare l'intera cartella lato server ? potrebbe occupare molto spazio e anche inutilmente

Mentre lo scrivevo, direi che conviene l'approccio 1 condiviso, però mi servono idee per sistemare contro "a"
Se avete altri approcci scrivetelo qui nei commenti