Haku #519

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on Dec 26, 2015, 17:44

Miten saadaan kunnolla toimiva Haku TIM-järjestelmään?

Dokumentin sisällä Ctrl-F toimii aika hyvin, mutta entä dokumenttien ulkopuolelta?

Haku-toiminossa miten haetaan sanoja joissa välilyönti?

Pitäisikö olla erikseen haku dokun nimestä?

Entä pitäisikö dokuihin voida lisätä avainsanoja joilla olisi nopeampi hakea?

Entä hakua alkaen jostakin kohti hierarkiaa?

Kun dokua nimeää uudestaan, olisi kiva tietää kuinnka paljon rikkoo samalla. Siksi nimeämisen vierellä voisi olla painke, jolla saisi automaattisesti ihan perushaun, jolla haetaan dokun viittauksia sekä nimellä että id:llä. Toki vielä varoitus käyttäjälle että haku koskee vain TIMissä olevia viittauksia. Voishan siinä toku myös käynnistää samalla Google haun ko URLeille.

Checklist

Ominaisuuksia:

[x] Hakutulosten määrä näkyviin
[x] Järkevämpi template hakua varten
[x] Tuloslista
[x] Haun rajoitus tiettyyn hakemistoon
[x] Haun optimointi (esim. jos paljon tuloksia, vain linkit kappaleisiin)
[x] Haku myös dokumentin nimellä tai sen osalla
[x] Dokujen avainsanat (tehty jo tageilla)
[x] Omistettujen dokumenttien haku
[ ] Ketkä lainaavat tätä -toiminto
[ ] Ketkä viittaavat tähän dokuun
[x] Hakutulosten aukaisu samaan ikkunaan asetuksissa
[ ] Vaihtoehtona hakutuloksien kohtia lainaavan dokumentin luominen
[ ] Kaikki paragraphit yhdistävän tiedoston luominen ajastetusti

Ongelmia:

[x] Virheilmoitus $digest already in progress enterillä haettaessa
[x] Lainauskappaleet, joissa on tekstiä esim. kommenttina aiheuttavat TypeErrorin tuloksien JSON-muunnoksessa (olioihin siirtyminen korjasi tämän)

Vesa Lappalainen

In GitLab by @Smibu on Jan 25, 2016, 21:17

Tuon voisi tehdä aika helposti niin, että kun menee vaikka

tim.jyu.fi/search/kissa

niin näytetään dokumenttinäkymän tapainen näkymä, jossa kappaleet ovat "lainauksia" niistä dokuista, joista "kissa" löytyi. Kappaleista voisi hakusanan maalata keltaisella tms. värillä. Sitten voisi klikata samalla tyylillä sitä linkkiä, joka vie alkuperäiseen dokuun vastaavan kappaleen kohdalle. Tuolla samalla sivulla voisi ylälaidassa olla hakupalkki. Siitä voisi yrittää tehdä "googlemaisen", eli esim. lainausmerkit tarkoittaisi, että pitää löytää tarkka osuma jne.

In GitLab by @Smibu on Jan 25, 2016, 21:31

@Smibu miten tuossa voisi ne oikeudet hoidella? – Vesa Lappalainen

In GitLab by @Smibu on Jan 25, 2016, 21:35

@vesal Haetaan vaan niistä dokuista, joihin käyttäjällä on view-oikeus?

In GitLab by @Smibu on Jan 27, 2016, 19:07

@vesal Nyt on alustavasti. Voi hakea vaikka: https://tim.jyu.fi/search/fxgui

Tuo on käyttäjäkohtaisesti tunnin ajan cachessa. Se voisi olla varmaan pidempikin.

In GitLab by @Smibu on Jan 27, 2016, 20:39

@Smibu Miksi muuten /hakusana eikä ?hakusana

Kumpi tarjoaa enemmän mahdollisuuksia erikoismerkeillä vai onko tuolla väliä? – Vesa Lappalainen

In GitLab by @Smibu on Jan 27, 2016, 20:48

@vesal Ehkä kauttaviivaa (/) on hankala kirjoittaa tuohon. Varmaan ?q=hakusana olisi tosiaan parempi.

In GitLab by @Smibu on Jan 27, 2016, 20:53

@Smibu Mutta oikeastihan tuolla tulee joskus johon (rattaan kuvan taakse) laatikko mihin hakusana kirjoitetaan. En tiedä saako URLiin laittta välilyöntejä yms.

Mutta ehkä tuo q=hakusana antaisi helpommin mahdollisuuden laittaa tuohon useammankin hakusanan. Tosin se pilkkominen hakusanoiksi ehkä on kuitenkin hakualiohjelman hommia. – Vesa Lappalainen

In GitLab by @Smibu on Jan 27, 2016, 20:57

@vesal Välilyönnit toimii (ainakin sanan välissä), mutta / ei toimi edes muodossa 'Reference to deleted milestone 2'F. Eli on tuo ?q=haku-muoto pakko melkein olla.

In GitLab by @Smibu on Oct 7, 2017, 09:59

Voisiko avainsanat toteuttaa seuraavasti:

avansanat ovat settings ja keywords kohdassa

keywords:
  - kissa
  - koira
  - kana

Aina kun settings tallennetaan, niin kantaa päivitetään vastaavilla avainsanoilla.
miten lainatut asetukset? Korjataanko sillä, että voi etsiä nopeasti dokuja jotka lainaavat valittua dokun kohtaa? – Vesa Lappalainen

In GitLab by @vivanauk on Jul 5, 2018, 15:23

created branch 519-haku

In GitLab by @vesal on Jul 5, 2018, 20:03

Minkälainen olisi tuo haun käyttöliittymä? Kannatatako siihen yhdistää tägihaku samaan, jossa käyttäjä valitsee että haetaanko

Hakusana: [kissa] [hae]

[ ] sanalla dokumenteista, alkaen: [kurssit/ohj]
[ ] tägeistä/avainsanoista
[ ] kursseista
[ ] dokumenttien nimistä

Osa noista on päällekkäisiä, mutta käyttäjän kannalta kurssi ja dokumentti voi olla eri asia, siksi ehkä sille oma valinta vaikka teknisesti olisikin sama asia.

Miten pitää haku yksinkertaisena, mutta silti helppokäyttöisena ja tehokkaana.

Miten valitaan mistä sanahaku alkaa, koska se on kallista tehdä "liian ylhäältä"? Jos ollaan Ohj1 jossakin demodokumenteissa, niin silloin haku pitäisi voida aloittaa ehkä oletuksena kurssit/ohj1 -kansiosta. Miten tämä ilmaistaan ja missä? Eli miten ilmaistaan "kurssin kotihakemisto". Joku esim ohj1 tapauksessa on ylempänä kuin kurssin kotisivu.

Miten käyttäjälle ilmaistaan minkäkin haun "hinta"?

Pitää testata aluksi kuinka korkealta hakeminen on vielä siedettävää.

In GitLab by @Smibu on Jul 6, 2018, 09:39

Miten pitää haku yksinkertaisena, mutta silti helppokäyttöisena ja tehokkaana.

Yläpalkissa voisi jatkuvasti olla näkyvissä hakupalkki, hieman kuten Stack Overflowssa. Sen yhteydessä olisi nappi, josta pääsisi jonkinlaiseen "Advanced search"-dialogiin.

Eli miten ilmaistaan "kurssin kotihakemisto".

Idea: Kansiolle voisi asettaa kurssitägin, jolloin dokusta/kansiosta X kiivetään ylöspäin niin kauan, kunnes löytyy kurssitägätty kansio. Tietokantahan jo tukee tägien antamista kansioille.

In GitLab by @vesal on Jul 6, 2018, 09:57

Miten kiivetään jos kansion tägiä ei ole. Eli mistä silloin aloitetaan etsintä?

ja entä jos käyttäjä on juuressa, annetaanko etsiä sieltä saakka?

mikä on oletushaku jos on vain hakukenttä?

In GitLab by @vivanauk on Jul 6, 2018, 14:14

Jos haku olisi yläpalkissa, niin mihin tulokset annetaan? Dialogiin vai uudelle sivulle?

In GitLab by @vesal on Jul 6, 2018, 14:26

Jos haku olisi yläpalkissa, niin mihin tulokset annetaan? Dialogiin vai uudelle sivulle?

Jos se dialogi syntyy dynaamisesti, eli ei haittaa sivua jos ei ole dialogia, niin miksei se voisi tulla dialogiin. Sitten käyttäjä voi itse valita avaako samalle sivulle vai eri sivulle sen dokun mitä klikkaa.

Dialogin kyllä pitäisi sitten olla rullaava, koska tuloksia voi olla paljon ja leveyden kanssa voi olla ongelma, eli en pidä poissuöjettuna sitäkään että tulokset aukeaisivat uudelle sivulle jolloin rullailu mobiileilla on luonnollisempaa. Tosin joskus kun aukaisee uudelle sivulle, niin se aukeaa jemmaan ja jää silloin huomaamatta vähempi käyttäneiltä. Tuon toiminta ei mobiileille pitäisi kokeilla ennen lopullista päätöksentekoa.

Ihannetilantessa seillä haun advaced osassa olisi ruksi että k umminko avataan ja se säilyisi local storagessa jollion jokainen voi omilla laitteillaan valita sopivimman tavan.

In GitLab by @vivanauk on Jul 9, 2018, 08:43

Hakuboksi on oikessa yläkulmassa. Sen asettelun kanssa oli vähän ongelmia, kun se tuuppaa muita elementtejä vasemmalle koska palkki menee melko täyteen.

Toistaiseksi haku on vain perusasetuksilla. Pitää myös miettiä tulosten näyttämistä. Erotellaanko kappaleet kuten nyt vai riittääkö että on vain lueteltu sivut joissa on yksi tai useampia tuloksia?

Laitoin sen myös testikoneelle, mutta jostain syystä komponentti ei näy siellä, vaikka lokaalilla koneella näkyy. Lähdekoodissa se on mukana, mutta enpäs vielä keksinyt miksi komponentin sisältö ei tule mukaan.

In GitLab by @vesal on Jul 9, 2018, 09:01

Toistaiseksi haku on vain perusasetuksilla. Pitää myös miettiä tulosten näyttämistä. Erotellaanko kappaleet kuten nyt vai riittääkö että on vain lueteltu sivut joissa on yksi tai useampia tuloksia?

Laitoin sen myös testikoneelle, mutta jostain syystä komponentti ei näy siellä, vaikka lokaalilla koneella näkyy. Lähdekoodissa se on mukana, mutta enpäs vielä keksinyt miksi komponentin sisältö ei tule mukaan.

Voisiko olla että typescriptit eivät ole kääntyneet?

Entä voisiko hakua olla niin, että siitä ei näkyisi oletuksen juuri muuta kuin suurennuslasi ja siten kun siihen osuu, niin se laajenee käyttölkepoiseksi vaikkapa jopa muiden komponenttien päälle.

Tuota esitysmuotoahan kannattaa sitten miettiä kun katsoo miltä tuo näyttää oikeassa tilanteessa, esim hakee ohj1 kurssin alta "aliohjelma"

Noita lohkojen tunisteitahan ei kannata näyttää. Tuossa voisi miettiä sitten kun saa toimimaan, jotakin sellaista, missa vähän kurssilistan tapaisesti löytynyt dokumentti on "avattavissa" ja sen alle tulee himpun sisältöä löytökohdista googlen tapaan. Tuota ei tietenkään voi hakea etukäteen, koska se varmaan kestää, joten se haku pitäisi tehdä vasta enemmän sitten kun dokumentti "avataan".

Aluksi sitä voisi kokeilla ihan niin, että olisi tyyliin:

Ohjelmointi1 (6 esiintymää)
Ohjelmointi2 (4 esiintymää) 1 (tässä voi tilapäisesti olla se lohkon id) 2 (lohkon id) 3 4
Tekoäly (2 esiintymää)

Sitten joskus noiden 1,2 jne linkkien tilalle siis himppu sitä lohkon sisältöä sen löytymissanan ympäriltä. Vättämättä tuota esiintymää-sanaakaan ei tarvita.

Vesa

In GitLab by @vesal on Jul 9, 2018, 09:16

Katsoppas näkyykö niitä sun TS muutoksia siellä F12 ja sitten Javasscriptin lähdekoodi.

In GitLab by @vesal on Jul 9, 2018, 09:23

Tuolta muuten tulee tuollaisia poikeuksia konsoliin:

system.js:4 GET https://timdevs1.it.jyu.fi/static/scripts/tim/services/parCompiler.ts 404 (Not Found) J @ system.js:4 (anonymous) @ system.js:4 Promise.then (async) We @ error: 404 Not Found

Samoin ngimport.ts ja csPlugin.js ja lazyLOad.ts

In GitLab by @vivanauk on Jul 9, 2018, 10:37

Ajoin päivitysskriptin testikoneella ja se näyttäisi ratkaisseen ongelman. Nyt pääsee kokeilemaan hakua.

In GitLab by @vesal on Jul 9, 2018, 11:32

Mitenkähän kun etsin hakusanalla "uusi"

ja löytyneeksi tuli mm:

kysely paragraph kjkuNAz6BadL

https://timdevs1.it.jyu.fi/view/users/lappalainen-vesa-tapani/kysely#kjkuNAz6BadL

ja kun tuota klikkaan, niin en löydä dokuemntista sanaa uusi?

Tosin tuo johtuu osin siitä, että tuota dokua avatessa konsoliin tulee virheitä.

Mutta nähtävästi sana "uusi" olisi pluginin sisällä, jota (???) käyttäjä ei näkisi. Kyselyistä on kahta eri versiota ja toisesta kysymyksen näkee ja toisesta vasta kun se luennolla kysytään.

Tästä poikiikin ehkä muunkinlainen ongelma liittyen esim csPluginine ohjelmien pisteytykseen ja oikeisiin vastauksiin. csPlugin YAMLissahan voi olla paljon tekstiä joka ei koskaa näy kenelleekkään. Ja periaatteessa jos näin etsimällä löytää sanoja, jotka pitäisi olla piilossa, se voisi mahdollistaa oikeiden vastausten kaivamisen Search-toiminnolla.

Tämä onkin syvällisempi ongelma jota joutuu miettimään kunnolla. Pitääkö jossakin sanoa että jos YAML-lohkosta löytyy etsittävä sana, niin millä ehdoilla (esim missä attribuutissa se esiintyy) sen saa näyttää.

Nopeuden takia tuota mahdollista ehtoa ei olene järkevä ajaa ensin, vaan vasta sitten hakutulosten selvittyä tarkistaa onko joku joka ei täytä ehtoa.

Sitten voi olla toisinpäin, eli voi olla paljon näytössä näkyviä sanoja, joita ei löydy lohkoista lainkaan, esim:

https://tim.jyu.fi/view/kurssit/tie/ohj2/materiaali/Tietokanta-vaihe-6#kerho-vaihe6-tietokanta-ohjelmaksi

jossa noiden listausten sisältö haetaan svn.ssä olevista koodeista. Ja jos tuolla on esim "CREATE TABLE", niin onhan se himpun kurjaa käyttäjän kannalta että sitten tuolla hakusanalla ko teksti ei löydy.

En tiedä onko tuohon olemassa mitään kunnon ratkaisua, koska TIM ei voi tietää mitä joku plugin tulee näyttämään ruutuun. Silloin periaatteessa pitäisi se sisältö käydä kysymässä pluginilta, mutta toisaalta paljon näkyvää tekstiä voidaan generoida vasta selaimen puolella, jolloin pluginin Python puoli ei edes välttämättä tiedä näkyvästi sisällöstä.

Eli haasteita tähän etsimiseen vielä näköjään tulee :-) Pitää nyt mennä ensin sillä, minkä kohtuudella saa aikaiseksi ja vaan kirjata näitä haasteita (esim. rukseiksi) ylös ja sitten päättää myöhemmin se, mille ei voi mitään.

Ehkä jokin ratkaisu voisi olla että kukin plugin lähettäisi TIMille tiedoksi siihen kappaleeseen kuuluvan näkyvän tekstin, jolloin TIM voisi sitä indeksoida. Liittyisikö tämä siihen, että jossakin vaiheessa TIM indeksoisi sisältöä aktiivisesti ja näin haut voisivat muutenkin nopeutua.

Mistä muuten haku nyt alkaa? Oikeassa TIMissähän jjuresta etsiminen ei ehdi valmistua timeoutin puitteissa.

Miten paljon esintymiä kannattaa näyttää erikoisdokumenteista kuten Bookmarks (tuo uusi tuli sieltä mulle ainakin 8 kertaa), premables, velps yms?

In GitLab by @vesal on Jul 9, 2018, 11:47

Tähän voisi lisätä jatkokehitystehtäväksi sellaisen, että jos se suinkin on selainten puolelta mahdollista, niin haun tulosksena aukaistavaan dokumenttiin vietäisiin parametrina etsimistoive tyyliin:

https://timdevs1.it.jyu.fi/view/testaus-2?search=uusi#W9qEHj1xjsx7

ja silloin selain sen omalla etsimistoiminnolla valaisi löytyneet sanat. Tai sitten jos mahdollista, niin selain käivis dokun läpi ja merkitsisi sanat jollakin taustavärillä (esim vaalean keltainen). Tuo työ vaan pitäisi saada taustalle, ettei se haittaisi dokumentin käyttämistä jos haku kestää kauan.

Nyt toki tuon voi itse tehdä niin että dokumenttiin saavuttuaa painaa CTRL-F ja kirjoittaa sanan uudelleen. iPadillä ja kännykälle tämä ei ole ihan niin helppoa.

Eli tämä tosiaan jatkokehitykseen kunhan saadaan tuotantoon ensin auttavasti toimiva versio.

In GitLab by @vesal on Jul 9, 2018, 11:57

Pitäisikö hakusana laittaa localstorageen ja näyttää sieltä aina joka sivulle. Nyt kun menee sivulle, niin siellä hakusana on tyhjä.

Odotellessa sitä automaattista maalausta, voisiko kuvitella että selaimesa pystyisi antamaan sen hakusanan valmiiksi phjaksi Ctrl-F:lle tai jopa tulemaan "lokaali suurennuslasi" tuohon viereen.

Jos hakusana on valmiina hakukentässä, niin toki siitä voi seurata se, että ihmiset tekevät heti uuden haun vaikka tulos on edeltä jo valmis. Miten voisi hyödyntää sitä muutama sekunti sitten tehtyä hakua niin, että ei heti haki uudelleen? Vai muutuvatko ehdot jos pääsivulla on hakenut ja sitten tulee dokumenttiin ja haku kohdistuu sen hakemiston takia suppeampaan osaan. Voisiko silti hyödyyntää edellistä hakua, eli voisiko hakujen tuloksia jotenkin cacheta? Jopa niin että jos toinen opiskelija heti kohta etsii samalla sanalla? Paljonko olisi silloin viive ennenkuin haku uusitaan, koska voihan sisältö oikeastikin muuttua? Tietääkö mistään missä sisältö on muuttunut, eli jos haun uusii, ei hakisi sieltä, missä on muutosta.

Miten haku muuten reagoi lainattuihin sisältöihin. Esim kun TDK-pöytäkirjaan on laitannut lakikohtia, niin löytyykö ko teksti vain lakiluettelosta vai näkyykö se myös pöytäkirjan yhteydessä?

In GitLab by @vivanauk on Jul 9, 2018, 12:29

Käytin haussa TIMin valmista search_in_documents-moduulin hakua, missä pystyi asettamaan ainakin onko mukana regexiä ja haetaanko kappaleiden exportatusta muodosta (minkä laitoin oletuksena pois päältä Mikan suosituksesta). Se tosiaan palauttaa myös asetuksista löytyneet jutut esim. tulostus templatet tulevat mukaan. En muutoin sen tarkemmasta logiikasta en ihan ole vielä selvillä tosin.

En tiedä onko tuohon olemassa mitään kunnon ratkaisua, koska TIM ei voi tietää mitä joku plugin tulee näyttämään ruutuun.

Yksi mahdollisuus olisi kai siivota pois hausta sellaiset pluginit, joissa on muutakin kuin mikä selaimessakin suoraan käyttäjälle näkyy. Haku siis vain puhtaasti tekstikappaleisiin ym. En ainakaan itse nimittäin odottaisi haun palauttavan asioita, jotka ovat piilossa asetuksissa ja muotoiluissa. Ja ehkä advanced searchiin ruksi, jolla haun rajoitukset voi ottaa pois?

Miten haku muuten reagoi lainattuihin sisältöihin.

Haku käsittääkseni näkee vain kappaleiden raakamuodon (lakilainauksien osalta se makro) eikä, kuten sanoit, tiedä mitä plugin tulee näyttämään.

Mistä muuten haku nyt alkaa? Oikeassa TIMissähän jjuresta etsiminen ei ehdi valmistua timeoutin puitteissa.

Nykyisellään haku hakee vielä juuresta lähtien, mutta meinasin seuraavaksi työstää kansion valintaa, mikä lienee tärkeimpiä juttuja tehdä. Olisiko oletuksena kohdekansioksi tarjottava joko kurssit, tai jos ollaan sen alla, niin nykyinen kansio / nykyisen dokumentin yläkansio?

In GitLab by @vesal on Jul 9, 2018, 13:03

Yksi mahdollisuus olisi kai siivota pois hausta sellaiset pluginit, joissa on muutakin kuin mikä selaimessakin suoraan käyttäjälle näkyy. Haku siis vain puhtaasti tekstikappaleisiin ym. En ainakaan itse nimittäin odottaisi haun palauttavan asioita, jotka ovat piilossa asetuksissa ja muotoiluissa. Ja ehkä advanced searchiin ruksi, jolla haun rajoitukset voi ottaa pois?

Joo, mutta sitten esim ohjelmalistauksissa on usein sanoja, jotka käyttäjä haluaisi nähdä, erityisesti jos ajatellaan jotakin Ohj1 tai Ohj2 monistetta.

Haku käsittääkseni näkee vain kappaleiden raakamuodon (lakilainauksien osalta se makro) eikä, kuten sanoit, tiedä mitä plugin tulee näyttämään.

Joo, niin se varmaan tekee. Aitojen lainausten (joka ei ole piilossa makron takana), se saattaisi hakea sen sisällön, koska se on sitä mitä toimitetaan selaimelle. Tsoin makronkin tapauksessa riippuen kummalta puolelta tuo etsintä tehdään, raakadatasta vaiko selaimelle lähtevästä koodista.

  Mistä muuten haku nyt alkaa? Oikeassa TIMissähän jjuresta etsiminen ei ehdi valmistua
  timeoutin puitteissa.
Nykyisellään haku hakee vielä juuresta lähtien, mutta meinasin seuraavaksi työstää kansion valintaa, mikä lienee tärkeimpiä juttuja tehdä. Olisiko oletuksena kohdekansioksi tarjottava joko kurssit, tai jos ollaan sen alla, niin nykyinen kansio / nykyisen dokumentin yläkansio?

Jos osaat käsin käyttää sitä hakuURLia, niin kokeileppä tuotanto (tai timbeta.it.jyu.fi) koneella kuinka kauan haku kestää kurssit-hakemistosta alkaen.

Tuo ongelma on minusta silloin kun aloitetaan pääsivulta. Mikallahana oli tuolla idea:

"Idea: Kansiolle voisi asettaa kurssitägin, jolloin dokusta/kansiosta X kiivetään ylöspäin niin kauan, kunnes löytyy kurssitägätty kansio. Tietokantahan jo tukee tägien antamista kansioille."

jota sitten voisi käyttää sivujen tapauksessa. Luulen että auttaisi jo paljon jos dokumentin tapauksessa kiivetääisiin tuohon kurssitägiin asti tai jos se ei tule vastaan, niin sitten niin ettei tulle kurssit-kansioon asti. Jos kiivetään muusta haarasta kuin kurssit, niin sitten yhtä vaille juureen (koska kurssit on suurin käsittääkseni). Eli /tim-kansioon aladokumentissa kun oltaisiin vaikka kuinka syvällä, niin noustaisiin /tim kansioon. Jos /kurssit/tietotekniikka/ohj1/2018k/ht/ohjeet/ohje-doku, niin ilamn kurssit-tägiä kiivettäisiin tietotekniikkaan asti. Tosin jos tuo kurssit on oikein jaettu, niin ehkä vielä voisi jopa lopettaa siihen organisaation alapuolelle, eli tuossa esimerkissä ohj1 olisi uuden haun aloituskansio. Haku toimi näköjään kansionäkymässäkin, eli siellä olisi samat säännöt.

Siis ennen tuota kurssitägin lisäämistä (että saadaan jotakin tuotantoon), voisi olla tuo em. tapa (ehkä niin että lopetetaan ohj1-kohtaan kurssit-alakansiossa ollessa). Silloin luulen että haku pysyy vielä siedettävän nopeana. Tuosta pääsivun hausta en vielä osaa sanoa. Sitä pitäisi kyllä rajata voimakkaammin kuin siihen kursseihin.

Tehdäänkö sitten niinpäin, että haku hakee aina myös tägeistä, koska se on kai nopeaa. Ja myös tiedostojen Title-nimistä, koska sekin kai tulee kannasta yhdellä kutsulla. Silloin käyttö olisi aika helppoa sen kuin kirjoittaa vain sanan.

Olisiko se jopa niin yksinkertaista pääsivulla, että siellä laittaisin alasvetolistaan kurssit/hakemiston hakemistojen nimet ja niistä pitäisi joku valita ennen aloitusta. Ja syvemmällä ollessa em säännöillä.

In GitLab by @vivanauk on Jul 9, 2018, 15:13

Lisäsin piilotettavan version, joka siis avautuu kuvaketta painamalla, ja johon saa vielä näkyviin lisäasetuspaneelin. Se ei vielä toimi esim. kansio ja manage näkymissä tosin. Näkyvyysasetukset sijaitsevat view controllerissa, mutta olisiko muissa tiloissa eri controllerit?

Asetuksina ovat alustavasti kohdekansio ja regex. Jos avaa kansiossa olevan dokumentin, niin kansioksi tulee toistaiseksi dokumentin yläkansio. En ole vielä rajoittanut juurihakuja.

Tuolta muuten tulee tuollaisia poikeuksia konsoliin: system.js:4 GET https://timdevs1.it.jyu.fi/static/scripts/tim/services/parCompiler.ts 404 (Not Found) J @ system.js:4 (anonymous) @ system.js:4 Promise.then (async) We @ error: 404 Not Found

Samoin ngimport.ts ja csPlugin.js ja lazyLOad.ts

Itselläni tuli vastaan vain kysely-dokumentissasi nämä. En mitään noista tiedostoista ole muuttanut, joten jokin ongelma varmaan haaran ajantasaisuudessa.

In GitLab by @vivanauk on Jul 9, 2018, 15:27

Voisi ehkä tehdä tuon myös niin, että napista avautuu suoraan paneeli, missä hakua ja kaikki hakuasetukset sen sijaan, että olisi kahdessa erässä laajentuvia juttuja. Tuo on vielä kokeiluversio aikalailla.

In GitLab by @vesal on Jul 9, 2018, 15:35

Lisäsin piilotettavan version, joka siis avautuu kuvaketta painamalla, ja johon saa vielä näkyviin

Vaihdetaanko JY-logo ja haku keskenään, niin haku ei karkaa niin oikelle. En vielä ehtinyt kokeilla ipadilla ja kännykällä, mutta hakujutut saavat ihan rauhassa avautua tuosta sitten vasemmalle vaikka peittäisivätkin muita juttuja.

lisäasetuspaneelin. Se ei vielä toimi esim. kansio ja manage näkymissä tosin. Näkyvyysasetukset

Annoin regexp ehdon siihen väärään kenttään ja sain vain huomautuksia että ehdon pitää olla 3 kirjainta pitkä. Folderin edessä on varmaan hyvä pitää joku lyhyt seliteteksti ettei sortuisi samaan kuin minä, koska se ohje on menetty

kirjaimen painamisen jälkeen :-)

Mutta tosiaan, tuo tarvinneet sitten tuohon esittämiseen sen että jos samssa dokussa ojn monta kertaa, niin se jää + -merkin taakse :-) Tuli aika pitkä lista kun etsin u.* :-)

sijaitsevat view controllerissa, mutta olisiko muissa tiloissa eri controllerit?

Siis eikös saman komponentin voi sijoittaa mihin tahansa näkymään. Jotakin sisäisiä optioita se saattaa vaatia eri tavalla.

Asetuksina ovat alustavasti kohdekansio ja regex. Jos avaa kansiossa olevan dokumentin, niin kansioksi tulee toistaiseksi dokumentin yläkansio. En ole vielä rajoittanut juurihakuja.

OK, pitää testailla.

Kokeilitko tuotantokoneessa tai beta-koneessa miten kurssit alta haku toimii?

  Samoin ngimport.ts ja csPlugin.js ja lazyLOad.ts
Itselläni tuli vastaan vain kysely-dokumentissasi nämä. En mitään noista tiedostoista ole muuttanut, joten jokin ongelma varmaan haaran ajantasaisuudessa.

Nuo tulenee aina jos dokussa on yksikin csPlugin. Pitää koittaa katsoa miksi nuo eivät ole tuolla. Ja missä vastaavat ovat toimivassa koneessa. Mikalta olisi kestänyt 1 min, mää koitan katso osaanko :-)

In GitLab by @vesal on Jul 9, 2018, 15:40

Voisi ehkä tehdä tuon myös niin, että napista avautuu suoraan paneeli, missä hakua ja kaikki hakuasetukset sen sijaan, että olisi kahdessa erässä laajentuvia juttuja. Tuo on vielä kokeiluversio aikalailla.

Totta, mutta toisaalta ihmiset vierastavat niitä optioita ja ehkä hyvä kompromissi olisi sellainen, missä oletuksena tulee vain se hakulaatikko ja siihen kirjoittamalla haetaan kaikista mahdollisista paikoista (sanahaku, tag-haku yms). Googlemainen yksinkertaisuus.

Sitten jos aukaiseen sen adcanced panelin, niin siellä on ruksi Open as default tms jolloin hevi-käyttäjä voi ruksia sen ja välttyy turhilta painalluksilta. Ja kaikki valinnat muistetaan (folderista en osaa sanoa, koska jos menen aladokuun, niin ehkä sitten se doku määrää sen folderin oletuksena, mutta jos juuritasolla tekee haun, niin folderissa voisi olla oletuksena se mistä edellisen kerran haettiin, eli folder ei tallentuisi muuta kuin juuritasolla (pääsivu) tehdyssä haussa.

In GitLab by @vesal on Jul 9, 2018, 15:49

Mitenkähän ilmaisisi että haku on meneillään?

Tein testikoneeseen haun (.) (kun pelkkä . ei kelvannut) ja sekin kesti jo aika kauan (tosin en tiedä kestikö haku vai tulosten teko). Kuinkahan paljon nopeuttaisi jos yksi optio olisi että yksi esiintymä/doku riittää ja sitten se tulee tuloksiin. Monesti silläkin pärjää kun sitten voi ctrl-f jatkaa.

Sitä en myös tiedä että pitäisikö rajoittua johonkin määrään löytöjä ja lopettaa. Esim jos löytöjä on yli 100 dokua, niin saako niistä enää kukaan selvää? Tuo voisi olla yksi optio siinä advanced-haussa (samoin ehkä tuo että 1/doku riittää). Etsii sitten noille hyvät oletukset kun käytännössä pääsee kokeilemaan.

Toinen rajoite voisi olla aikarajoite, eli haku lopetetaan jos on se 100 dokua löytynyt tai kestää n. 10%-75% siitä ajasta joka on selaimen timeout haulle. Silloin oppii tekemään haun "alempaa"

In GitLab by @vesal on Jul 9, 2018, 15:51

Työntääköhän muuten tuo aukeava advanced-alasveto turhaan muuta dokua alaspäin. Se voisi olla sellainen "popup" joka tulee muiden päälle.

TIMiä on moitittu siitä että teksti pomppii liikaa ja sitä varmaan pitäisi koittaa välttää ja keksiä miten olemassa olevissakin tuota vähentäisi.

In GitLab by @vesal on Jul 9, 2018, 16:06

Joo, noihin mun aikaisempiin "sääntöihin" se että mistä haku aloitetaan, niin jos ollaan käyttäjän hakemistossa, niin oletuhakupaikka voisi olla aina nousta siihen käyttäjän juureen, eli esim mun tapauksessa dokusta

users/lappalainen-vesa-tapani/vesan-volderi/vesan-volderissa-oleva-doku

hakisi oletuksena kansiosta:

users/lappalainen-vesa-tapani

Jos on vieraassa folderissa niin sitten en osaa sanoa.

Eli "säännöt" toistaiseksi

oletus dokumentti users/lappalainen-vesa-tapani users/lappalainen-vesa-tapani/vesan-volderi/vesan-volderissa-oleva-doku kurssit/tietotekniikka/ohj1 kurssit/tietotekniikka/ohj1/2018s/demot/demo1 tim tim/ohjeet/kehittajille/admin

ja siis pääsivulla hakukohde olisi valittava listasta tyyliin:

users/lappalainen-vesa-tapani tim kurssit/tietotekniikka kurssit/fysiikka kurssit/kemia

Jos saa sellaisen komponentin, johon ssaa kirjoittaa tai valita listasta, niin tuo listahan voisi aina olla siinä. Saisi kirjoittaa mitä vaan tai sitten tuo lista suppenee ja voi kirjoittaa muutakin tai valita sitten listasta mieleisensä.

En tiedä saisiko folderin nimessä käyttää regexpiä?

Eli folderiin saisi kirjoittaa

kurssit/tietotekniikka/ohj?

In GitLab by @vesal on Jul 9, 2018, 16:24

Kännykässä toimi aika hyvin. Olisi ehkä vielä helpompi jos suurennuslasin painamisen jälkeen sanakenttä aktivoituisi. Nyt pitää pari kertaa klikata.

Toimii hyvin myös iPadissä. Tuo on jännä ominaisuus että noita löytymisdialogeja aukeaa useita, mutta ehkä sen voikin pitää ominaisuutena, sillä voihan sitä hyödyntää jos etsiin ensin kissoja ja sitten kanoja, niin voi aukoa niitä dokuja siitä. Sekin on osin kiva että jos samaan dokuun tulee esiintymä, niin klikkaaminen vain siirtyy siihen kohtaan sulkematta dialogia.

Mutta se sanan säilyminen on vielä kiva lisä tuohon että haun voi toistaa. Tarviiko silloin jonkun tyhjennysruksin laatikon viereen?

Se voisi olla tuollaisen edit-laatikon perusominaisuus, että siinä on pieni tyhjennysruksi reunassa..

In GitLab by @vesal on Jul 10, 2018, 07:38

Oikeastaan jyu logon saa uhrata kun suurennuslasin avaa. Se saa ihan hyvin jäädä aukeavan editin alle. Tällöin kännykässä ei mene yhtä riviä hukkaan.

Toki voi olla niin että jos leveys on yli jotakin, logo säilyy, mutta ei ole välttämätöntä.

Logohan tukee kuitenkin aina esiin kun avaa uuden sivun.

In GitLab by @vesal on Jul 10, 2018, 08:29

itse asiassa kännykällä toimii paremmin kuin ipad, kosks hakemiston edit on koko näytön levyinen ja ipadissä se jää niin kapeaksi että ei juurikaan näy edes oma nimi. Eli ipad leveydellä ainakin voisi advanced vien leveyttä isontaa.

Tähän varmaan auttaisi tuo logon uhraaminen. Sitten advanced viewn z voisi olla isompi, jolloin teacher view yms dialogit jäisivät sen alle, mutta toki yhtä pienempi kuin hakutulosten.

In GitLab by @vesal on Jul 10, 2018, 08:49

kännykällä suurennusladi mahtuisi pari milliä enemmän oikealle

In GitLab by @vesal on Jul 10, 2018, 08:56

piäisiköhän hakutuloksissa näyttää hakupolku pienellä otsikon yläpuolella?

Sitten dokujen nimet eivät sina kerro koko totuutta.

Jos dokun nimi olidi se + avattava, jota klikkasmalla kuitenkin mentäisiin dokuun mahdollisesti se hakusana parametrina, niin avasmisen jälkeen voisi näkyä dokun polku (julkiset polut) ja mhdollisesti jos joskus tulee se hakemiston kurssikoodi, niin myös dokun hakemistoa vastaava kurssikoodi. Sitten sen alla alekkain ne löytötulokset.

Löytymispolku em voisi olla aika pienellä. titlessä voisi olla dokun kokonimi polkuineen.

In GitLab by @vivanauk on Jul 10, 2018, 09:09

Paljonlaisesti on huomioitavia asioita tässä.

Kokeilen nyt sellaista, että koko haku aukeaa paneelin sisään kaiken muun päälle niin ettei tule sitä elementtien hyppimistä.

Lisäksi asetukset ja hakusana tallentuvat (folderia lukuunottamatta, ainakin vielä) ja advanced options voi asettaa oletuksena tulemaan päälle.

In GitLab by @vivanauk on Jul 10, 2018, 09:15

marked the task Haun rajoitus tiettyyn hakemistoon as completed

In GitLab by @vesal on Jul 10, 2018, 09:17

Kokeilen nyt sellaista, että koko haku aukeaa paneelin sisään kaiken muun päälle niin ettei tule sitä elementtien hyppimistä.

Olitpa nopee...

Kännykällä saisi olla 100% leveys. kapeni nimittäin siitä edellisestä versiosta.

hakutulosten z yhtä isommaksi, mulla jää hakutulokset hakufialogin taakse.

In GitLab by @vesal on Jul 10, 2018, 09:22

oisko dialogin aukeamispaikka niin että ruksi tulee suurennusladin kohdalle? kännykällä se menee niin ja mukavasti voi avata ja sulkea siirtämättä sormea.

Sitten vielä se fokus valmiiksi hakusanan kohdalle ja sille select sll, niin voi heti slkaa kirjoittamaan

In GitLab by @vesal on Jul 10, 2018, 09:27

vai olisko remember advanced parempi?

vai tarviiko se edes ruksia jos se on aina remember advanced?

In GitLab by @vesal on Jul 10, 2018, 10:21

Nyt hakudialogi aukeaa leveällä PC näytöllä tosi leveänä, mutta kännykällä vielä ehkä 70% leveydestä. PC:llä voisi olla jonkin verran kapeampi ja kännykällä se 100%.

Dialogin kotnrollit voisivat olla vasemmassa reunassa, rexexp on niin yksinäinen tuossa keskellä :-)

regexpin perässä voisi olla ?-linkki, joka veisi dokuun jossa kerrotaan asiasta. Ehkä ihan siihen perustimhelppiin jossa jossakin kohti kuvataa yksinkertaisesti regexpiä.

Ehkö jopa niin että ensin on sana regexp ja senjälkeen se ruksi, niin olisi enemmän linjassa Folder: kontrollin kanssa?

Tuon yläpalkinleveydensäätö on hieman omituinen. Jos tuon osaa (Vista tai Rami) korjata, niin ei haittaisi :-) Nyt leveällä näytöllä se on aika leveällä, paljon teksitä leveämpi. Siitä kun lähtee selainta kaventamaan, niin se kapenee hyvin voimakkaasti ja menee jopa tekstiä kapeammaksi jossakin vaiheessa, kunnes sitten pomppaa näytön leveyiseksi. Parempi olisi ehkä että se olisi himpu tekstiä leveämpi silloin kun mahtuu ja sitten kun ei mahdu, niin näytön levyinen.

Mulle muuten tulee konsoliin virheitä kun tekee hakua?

In GitLab by @vivanauk on Jul 10, 2018, 10:50

Nyt hakudialogi aukeaa leveällä PC näytöllä tosi leveänä, mutta kännykällä vielä ehkä 70% leveydestä. PC:llä voisi olla jonkin verran kapeampi ja kännykällä se 100%.

Paneeli alkaa siitä login menun kohdalta ja kokeilin ottaa leveyden muut rajoitukset pois, sen takia se käyttäytyy noin. Hyvänä puolena se ei kännykällä pitäisi peittää hampurilaismenua.

En ole vielä keksinyt miten paneelin saisi aukeamaan suurennuslasin kohdalta ja levenemään oikealta vasemmalle, silloinhan se ei menisi ruudusta yli ja olisi aina näppärästi ruksi oikeassa kohtaa. Kokeilen vaihtaa nyt niin, että vaikkapa yli 600px ikkunassa se aukeaa pienempänä. Voisi myös yrittää säätää niin, että jos on kapea näyttö, se alkaa aivan vasemmasta reunasta ja täyttää koko rivin, ja jos on leveämpi, niin alkaa vasta puolesta välistä.

Hakutuloksissa jätin myös pois samassa kappaleessa olevat eli näyttää vain paragraphit, joissa on yksi tai useampi tulos.

Mulle muuten tulee konsoliin virheitä kun tekee hakua?

Minulla tulee virheitä vain enteriä painamalla haettaessa. Käsittääkseni se johtuu siitä, kun async funktiota kutsutaan jotenkin väärässä syklissä. En ole vielä keksinyt korjausta tuohon. Tulokset tulevat näköjään kyllä siitä huolimatta normaalisti.

In GitLab by @vesal on Jul 10, 2018, 10:55

Paneeli alkaa siitä login menun kohdalta ja kokeilin ottaa leveyden muut rajoitukset pois, sen takia se käyttäytyy noin. Hyvänä puolena se ei kännykällä pitäisi peittää hampurilaismenua.

Entö jos sille antaa absoluuttileveyden joka on sellainen että kohtuullisen hakupolun saa kirjoitettua ja sitten jos näyttö on kapeampi, niin näytön leveyinen. En tiedä haittaako vaikka peittää hampurilaismenun, koska kuitenkaan juuri mitään ei saa tehtyä ennenkuin sulkee hakuikkunan.

Laita ruksi siitä konsolin virheestä niin ei unohdu tehdä vaikka nyt jatkaakin eteenpäin. Saisiko sen jollakin single-shotilla tehtyä että pääsisi pois siitä metodista jossa enter tulkitaan?

In GitLab by @vivanauk on Jul 10, 2018, 10:58

Paneelin leveyden rajoitus ei näemmä toimi etusivulla, mutta dokumenteissa toimii. Tässä oli muutenkin se ongelma, että controller vaihtuu eri tilojen välillä ja tuon avaamiseen liittyvät funktiot eivät löydy.

In GitLab by @vesal on Jul 10, 2018, 11:17

Paneelin leveyden rajoitus ei näemmä toimi etusivulla, mutta dokumenteissa toimii. Tässä oli muutenkin se ongelma, että controller vaihtuu eri tilojen välillä ja tuon avaamiseen liittyvät funktiot eivät löydy.

Minusta muuten tuli aika hyvä jo noilla:

element.style { position: absolute; z-index: 2; right: 0; left: auto; width: 600px; }

ja sitten media stylellä että jos menee alle 600px näyttö, niin width: auto, left: 0

Tee muuten tuiostakin oma class joku tyyliin: "search-dialog" ja seta tyylit siellä, mahdollisimman vähän elemnt.stylejä, niin voi sittn käytöstä muuttaa paremmin (s)css:llä ja siis myös itse kustomoida.

In GitLab by @vesal on Jul 10, 2018, 11:21

width: 600px;

Ehkä jopa 500 riittää?

In GitLab by @vivanauk on Jul 10, 2018, 11:36

Toimisiko max-width ilman lisätarkasteluja kapeilla näytöillä? Lokaalilla koneella ainakin näyttäisi toimivan. Sain myös ujutettua divin sisällä paneelin aina alkamaan siitä search togglen kohdalta.

In GitLab by @vesal on Jul 10, 2018, 11:40

Toimisiko max-width ilman lisätarkasteluja kapeilla näytöillä? Lokaalilla koneella ainakin näyttäisi toimivan. Sain myös ujutettua divin sisällä paneelin aina alkamaan siitä search togglen kohdalta.

aika pitkällehän sitä voi kokeilla niillä chromen näyttöasetksilka ja monesti myös kaventamalla näyttöä. Nyt tuntuisi etsintädialogi toimivan aika hyvin mitä kokeilin.

tulosdialogi sen sijaan on kännykällä liian leveä

TIM-JYU / TIM

Haku #519

Checklist