piler helyzetjelentes

Az FSF-palyazatra beadott egyik mu mar szinte surolja a hasznalhatosag hatarat. Ime egy helyzetjelentes, hogy hol all a projekt, nemi screenshot-tal megtamogatva. Kattintva nagyobb lesz!

Mi a piler? Egy vallalati email archivalo megoldas, amely SMTP-n fogadja a leveleket, es feldolgozas utan tarolja azt, ill. egy webfeluletet biztosit a levelek eleresere a felhasznalok szamara. A piler nyilt forrasu program, es szinten open source eszkozoket hasznal a feladatainak elvegzesere.

Egy szokasos login ablak, ahol az adott user az o tetszoleges email cimevel be tud jelentkezni.

Bejelentkezes utan a felhasznalo a sajat leveleit latja, idorendben visszafele. A jobboldali kis zold ikonok azt jelzik, hogy az uzenet ellenorizve lett, es senki nem modositotta azt. Az ellenorzeshez szukseges kriptografiai muveletek azert idobe telnek, de meg egy nem tul eros epen is megvan 1 sec alatt.

Nezzunk egy keresest, hogy kik hamisitottak az email cimemet. A keresesi felteteleket a web felulet elmenti, ami foleg osszetettebb kereseseknel lehet hasznos.

Akik szerint karesz vagyok az ágyban (hehe) :-)

Pelda osszetett keresesre. Max. 5 db cimzettet es ugyanannyi feladot lehet megadni, amelyek OR kapcsolatban vannak/lesznek egymassal. A subject es a body kulcsszavai AND kapcsolatban vannak, hacsak mashogy nem rendelkezunk (OR).

Egy fokkal meg cifrabb kereses. Erdemes megnezni az 5. talalat es a subject elso keresesi kifejezesenek viszonyat. A keresest amugy a sphinx search nevu cucc vegzi, ami a 2.0.x(?) verzio ota egy kellemes SQL feluletet is biztosit az eleresre. Ez a sebessege mellett abszolut pozitivum mellette.

Az egyes uzenetekhez cimkeket tud rendelni a tulajdonosa, amelyekre szinten keresni lehet. Jelenleg van egy olyan limit (es meg az is lehet, hogy ez megmarad), hogy vagy a cimkekre lehet keresni XOR barmi masra (pl. felado, targy, stb.), mert a cimkek kulon sphinx indexbe kerulnek.

Az uzenetet online meg is lehet nezni. Egy popup ablakban jon fel az eredmeny. Fontos! A user (nyilvanvalo okok miatt) nem tudja torolni a sajat (sem pedig masok) leveleit.

Tul sok beallitanivalo nincs, csak a nyelv, lapmeret es a theme.

Az adminisztratorok kulonfele statisztikakat lathatnak a rendszer allapotarol. Jelenleg eppen egy prefork-olo verziot tesztelek, es a te dontesed, hogy akarsz-e a piler ele postfix-et. Ha szukseged van TLS/SSL-re a levelek SMTP-n tovabbitasahoz, akkor kell egy smtp szerver a piler ele. Moge mindenkeppen, mert a level helyreallitasahoz/smtp-n exportalasahoz szukseg van ra.

Az archivalt uzenetek szama grafikusan is lathato.

A felhasznalokat menedzselni is lehet. Alapvetoen nem kezzel kell felvenni oket, hanem AD-bol, LDAP-bol lehet oket szinkronizalni egy CLI programmal (akar crontab-bol is). Azert kell a user infokat atvinni az archivalo dobozra, hogy a piler eldonthesse, hogy egy levelet jogosult-e a felhasznalo megnezni.

A projekt weboldala meg nincs feltoltve, de hamarosan az is sorra kerul.

Hozzászólások

Esetleg 2-3 mondatban osszefoglalni, hogy ez MI..?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

update-eltem a leirast, ime:

A piler egy vallalati email archivalo megoldas, amely SMTP-n fogadja a leveleket, es feldolgozas utan tarolja azt, ill. egy webfeluletet biztosit a levelek eleresere a felhasznalok szamara. A piler nyilt forrasu program, es szinten open source eszkozoket hasznal a feladatainak elvegzesere.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

attol, hogy ez nem a user gepen levo pst, hanem egy kozponti archivum, ami fuggetlen a userektol, annak minden elonyevel, pl. deduplikalas, tomorites, titkositas, kereshetoseg (ugy ertem pl. auditor is kereshet benne), szabalyozhato, hogy mit es meddig tarolj, a user nem tudja torolni, modositani a szamara kompromittalo adatokat, nem vesz el az adat, ha a user gepeben levo diszk meghal, stb.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Amit én láttam eddig: Archiválod a local gépedre (lokális mailboxba) a cuccot. (Elég nagy vállalatok voltak, ahol ezt láttam.)
Ezt én egy nagyon béna megoldásnak tartom, tiszta gáz.
Szóval egy óriási +1 a projektnek és nagyon drukkolok, mert nagyon jó lenne egy nyílt, valóban használható megoldás.

Amit én láttam eddig: Archiválod a local gépedre (lokális mailboxba) a cuccot.

Ez tenyleg komoly :-)

Szóval egy óriási +1 a projektnek és nagyon drukkolok, mert nagyon jó lenne egy nyílt, valóban használható megoldás.

Kossz, reszemrol ezen leszek. A core feature-ok hamarosan elkeszulnek, de aztan kellenek majd a ti visszajelzeseitek.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Szoval a .pst epp olyan jo, ha nem jobb, leven az is keresheto...

azert en feature-ben egy *kicsit* tobbet tudok majd ennel. Az email archivalas azert nem egeszen ugyanaz, hogy idonkent kiirom szalagra a mail szerver mailboxait. Backup != archivalas

http://www.mailpiler.org/wiki/doku.php/main:features

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

utana nezek az exchange 2010 online archive, kossz a tippet.

Btw. mennyire bonyolult egy olyan keresest vegezni, hogy gyujtsuk ki az osszes olyan levelet, amit a ceg dolgozoi az xxx @ aaa.fu cimre kuldtek 2010-2011 kozott, es ellenorizzuk le azt is, hogy az igy megtalalt levelek nem-e lettek modositva pl. egy belso attacker altal? Akar az online archive, akar a halozatra feltolt pst-kkel megoldva...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

egy ekkora archivumnal sem kell a teljes 20-30 GB-ot elovenni es on-the-fly ellenorizni, hanem eleg azt, amire szukseged van. Egy win xp-t futtato desktop pc-n vmware-ben a webes felulet 20 db levelnel (beleertve a level archivumbol eloallitasat is) ~0.5 sec alatt vegez. Ha cli-bol akarsz egy nagyobb mennyiseget exportalni, es verifikalni, akkor ott elfogadhato az extra terheles. Btw. enelkul aligha lehetsz biztos abban, hogy valoban az eredeti levelet latod.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

+1

Teljesen normalis hogy az ember az archivumait is modositja es a securityt mashol kezelik le nem pedig minden egyes levelnel; igy pl. adja magat alatolni egy verziokezelot, archivalva emellett amugy is van, security meg mashova tartozik => nem latom az ertelmet mindent az alkalmazasba betolni mikor nem oda tartozik, plane vallalati kornyezetben ;)
--
cythoon

nem tudom, mennyiben modositja az ember az archivumat, de ez (imho) max. addig terjedhet, hogy ujabb levelek kerulnek bele, esetleg az elore definialt retention policy alapjan toroljuk a leveleket, ami pedig belekerult, az nem valtozhat. De kb. ennyi. Azt meg elmagyarazhatnad, hogy egy verziokezelo megis hogy kerul a kepbe, ill. hogy a security hova tartozik, es miert nem tartozik az archivalashoz?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

neked lehet, hogy nem, de legalabbis kulfoldon letezik ez a compliance nevu eloiras. Tobb ilyen is van (agazattol is fugg, hogy melyik), pl. SEC, SOX, HIPAA, stb. Ezek tobbsege (ha nem eppenseggel mind) eloirja, hogy az archivalt leveleket digitalis alairassal el kell latni. Es ha mar kell ilyen, akkor azt hasznalni is kell. Mondom, egy atlag hazai cegnel ez boven overkill lehet (meg jelenleg), de ha egy ellenorzes lesz, ahol az emaileket bizonyitekkent kell bemutatni birosag elott, akkor az keves, hogy 'csinaltam egy tar.gz-t a levelekrol'.

Szoval ezert akarok egy olyan megoldast, ami nem azon bukik el, hogy ugyan minden feature-t tud, ami a cegnek kell, de nem felel meg pl. a PSZAF eloirasoknak. Mondjuk a PSZAF-nek pont nincs ilyen eloirasa jelenleg :-), de beadok egy kervenyt, hogy csinaljanak.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Ha az archivator magatol irja ala digitalisan a levelet, akkor siman raveheto (foleg ha van import stuff hozza) hogy akarmit alairjon neked. Kitorlok egy levelet, beimportalok egy masik verzioju levelet, az alairas sertetlen lesz rajta, de mar nem ugyanaz lesz a tartalma, mint amit szeretnel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

a kereskedelmi termekeknel tobbnyire ott van a 'tamper-proof' jelzo. Egyszer rakerdeztem az egyiknel, hogy ha elottem a cucc, amihez 'root' jogom van, akkor mi modon nem tudom azt megpiszkalni? Ezt valaszolta:

"please understand that we are not going to argue with you, if you tell us that it is not temper-proof if you put a high amount of criminal energy into manipulation of the archive. Even if you manage to modify the container file where the the encrypted MIME parts are stored the chanced are good that you ruin the whole container file, making it impossible to retrieve the data ever again.

Temper-proof in terms of being legally compliant, means that you cannot modify the archive easily without very special knowledge about encryption and the way an email is stored in xxxxxxxx. Everything else might just be marketing speech, you know.

In my opinion the highest barrier is the combination of an undocumented file format of the container files, compression, encryption and hash values. Of cause you might easily get around one of them. But in that combination you must have hired a very evil hacker."

En ehhez kepest hatranybol indulok az open source megoldasommal, mert eleve atlathatonak tervezem. Amugy lesz hozza import utility :-), bbar az, ha ugyanaz is a level, egy uj id-t rendel hozza, szoval a mar tarolt levelet ill. a metaadatait nem bantja).

Azonban ennek ellenere sem remenytelen a helyzet, mert mi van, ha az egyes leveleket osszefuzom? Minden level metaadatanak eltarolom a hash-et, aminek a kepzesebe beleveszem az elozo 2 level hash erteket. Igy ha barmit is modositasz, megbomlik a lanc. OK, egy verifikalas nyilvan nem mehet az osrobbanasig vissza. Ill. meg egy kereskedelmi megoldasnal sem lattam, hogy kulso TSA-t vesznek igenybe, es mondjuk orankent alairjak vele a metaadatokat. Ez korrekt kulso TSA eseten korrekt vedelmet ad meg a rosszindulatu rendszergazda ellen.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Itt ugye a konnyusegen mulik minden, egy import utility-t nem tul nehez hasznalni.

Es hogyan akarod osszefuzni oket? Per cim, vagy ugy globalisan az osszeset? Mert ez utobbi esetben a visszakereses eleg lassu es fajdalmas lesz.

Mondom, a teszteket mindig vegezd el egy tobbezer-tizezer leveles bazison is, hogy realis kepet kapj a megoldas sebessegerol. Es mindent ehhez kell szamolni, mert egy cegnel sosem fog elofordulni az, hogy az archivumban husz level van. A valaszidonek pedig meg tobbezer level eseteben se szabad max 3-4s fole menni, mert az mar lassu es hasznalhatatlan.

Szerk: most latom, hogy valaszoltal erre a masik szalban
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Es hogyan akarod osszefuzni oket? Per cim, vagy ugy globalisan az osszeset? Mert ez utobbi esetben a visszakereses eleg lassu es fajdalmas lesz.

Nem, nem igy. A metadata tablaban a beerkezes/archivalas sorrendejeben vannak a levelek. Amikor beesik egy level, akkor az elozo 2 level metaadatainak hash-evel fuzom ossze. Igy ha megvaltoztatod a 32876. levelet, es a hozzatartozo osszes metaadatot + hash-eket, akkor az el fogja szurni az utana kovetkezo osszes level hash-eit. Ezert ha pl. egy 2 hettel ezelotti levelet akarsz eszrevetlenul modositani, akkor az utolso 2 het osszes levelet annak megfeleloen modositanod kell, hogy ne lehessen kiszurni a disznosagot, ami imho nem annyira trivialis. A kerdes az, hogy praktikusan hany 'utana' levelet nezzunk meg?

valaszidonek pedig meg tobbezer level eseteben se szabad max 3-4s fole menni, mert az mar lassu es hasznalhatatlan.

Ez nem egeszen igy mukodik. Egy atlag webes kereses eredmenye mindig lapozva jelenik meg, azaz a bongeszonek csak ~20 level eredmenyet kell megvarnia. Ha pl. jon egy auditor es azt mondja, hogy kell az osszes tavalyi level, amit a @aaa.fu cimre kuldtek a dolgozok (ez legyen mondjuk 50k level), akkor azt ugy fogjak kiexportalni, hogy lefuttatnak egy cli programot, ami a megadott helyre kiteszi ezt a zsak levelet. Persze, jo, ha ez is hamar megvan, de itt kevesse szempont az, hogy azert kelljen sietni, nehogy a brozer timeout-ra fusson.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Akkor biztos csak en nem ertem a koncepciot. Adott mondjuk egy ceg, napi 1000-2000-es levelszammal. Adott egy fiok, ami ebbol relative ritkan kap levelet, mondjuk napi ketszer. Ennek a fioknak az archivumaban akarunk keresni. Ha kereses kozben az osszes utba eso levelet vegigkoveted (hiszen csak igy lehet megbizni a lancban), akkor az eleg lassu lesz. De valszinuleg inkabb nem ertem a koncepciot,
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

De, jol latod. Viszont szerintem nem kell az osszes elemet leellenorizni, hiszen kevesse realis, hogy a tamado az osszes szukseges elemet modositja. Ill. lehet ugy csinalni, hogy pl. orankent lebelyegzed, es akkor az adott levelnel csak az adott ora hash-einek osszefuzott eredmenyet kell osszevetni a belyeggel, ami nem annyira gaz.

En meg azon is gondolkoztam, hogy csinalok egy nem open source (csak binarisan terjesztett) .so file-t, ami a beolvasott titkosito kulcsot osszekeveri, igy megnehezitve a tamado dolgat. (De mi van, ha a memoriat nezi? Vagy akkor, ha egy 32x akkora teruletre teszem, ...)

De ez az egesz verifikalas dolog mikentje, hogy mennyire kell megbonyolitani, az attol is fugg, hogy mennyire paranoid a ceg. Mondjuk a kulfoldi szabalyozasok eleve megkovetelik, hogy a leveleket _2_ peldanyban ird ki, amibol az egyik peldany egy WORM drive-ra kerul.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

egyelore ~3200 level (79 MB) van, amit

real 0m13.851s
user 0m1.872s
sys 0m4.820s

alatt exportalt ki digest ellenorzessel egyutt. De ha egyszer egy fizikai vasat (vagy egy korrekt virtualis gepet) is allokalni tudok a temara, akkor beletolom az idei osszes levelem, es ugy is csinalok egy benchmarkot.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Van-e arra valami mód vagy terv, hogy a meglévő 10-20 user 10+ év levelezését belapátolja az ember?

Hat ebbe usability-ileg bele kene nyulni picit, meg mielott tul nagyra no, ugy nez ki, mintha a 90-es evekbol szallt volna ide, bar a squirellmailnek tuti jo kiegeszitoje.

Forraslink (github, google code, bitbucket, etc) van valahol?

Jo lesz ez, csak a modern webfeluletek temajaba meg nem astad bele magad ahogy nezem...

Hat ebbe usability-ileg bele kene nyulni picit, meg mielott tul nagyra no, ugy nez ki, mintha a 90-es evekbol szallt volna ide, bar a squirellmailnek tuti jo kiegeszitoje.

:-))

Forraslink (github, google code, bitbucket, etc) van valahol?

A www.mailpiler.org-rol lehet letolteni. Hamarosan kiteszek egy linket egy kesz config.php-val. (csak addig nem akartam nagyon eloresietni, amig egy kb. hasznalhato doksi el nem keszul).

Jo lesz ez, csak a modern webfeluletek temajaba meg nem astad bele magad ahogy nezem...

Hat igen. Ebben azert el kelne egy kis segitseg...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Ha adsz forrast kapsz valamennyit, de anelkul nem fogom megerteni hogy _pontosan_ mi a fenet akar ez a szoftver (ill. de, ha adsz komplett funkcionalis speckot, de szerintem forrasod elobb lesz)

A mailpiler-t neztem posztolas elott, telepitesi instrukciokat igen, forrast nem talaltam.

Hogy mennyi idom lesz az jo kerdes, lehet kapsz kodot, lehet kapsz mockupot, de lehet csak egy rakas pattern-t, hogy mit kene mashogy csinalnod es miert. Azt legalabb mashol is tudod hasznositani.

Szia,

kapsz egy ilyet: https://dl.getdropbox.com/u/7067930/piler_oss_ux_report.pdf

Eloszor olvasd el, es dontsd el hogy a qrvaanyamat-e. Azert hosszu, mert teli van kepekkel, hogy masok hogy csinaljak, es magyarazatokkal, hogy az miert ugy van, vagy a pilerben ami van az ugy miert nem jo esetleg.

Amire lusta voltam: ajnarozni. Szepen nez ki a piler a HTML-forraskodjahoz kepest (errol majd kulon irok), de idom elsosorban, jo magyar modra, arra volt, hogy a hianyossagokat felsoroljam.

Nyilvan ez egy 0.1-es verzioju szoftver. Nyilvan egy csomo mindenre magad is gondoltal, tervezted, de nem volt ra idod egyszeruen, persze.

Ezert leginkabb egy keretet szerettem volna adni, hogy miben kene gondolkodni, mikor feluleteket tervezunk. Nem lett altalanos munka: a piler-en keresztul mutatja be, hogy kepzelik a UX-esek hogy kell atlatni, mi hoz es mi visz egy felulettel kapcsolatosan. Nyilvan nem is teljes.

A tartalomjegyzeket azert kiirom ide, hatha mas is kedvet kap:

- Bevezető
  - Módszertan
    - A piler elhelyezése a szoftverek világában
  - Más hasonló szoftverek
  - Elméleti módszertanok
    - Kereséselmélet: Bool-algebra
    - Norman usability elmélete
    - CRAP design-elmélet
    - Pattern Language elmélet
    - Use case elmélet, User Stories
    - Persona technika
- Más hasonló rendszerek
  - A rendszerek interfészeinek bemutatása
  - Minták más rendszerek vizsgálata alapján
    - Egyszerű keresődoboz
    - Egyszerű keresés mezőn belül
    - Mező típusa alapján más interfész
    - Dinamikusan bővíthető keresés
    - Eltárolható keresések (filterek)
    - Keresés csatolmány típusa alapján
- A Piler elemzése
  - A Piler felhasználóinak perszonifikációi
    - Alíz
    - Jani
  - A Piler vizsgált felhasználási módjai (User Stories)
    - Alíz: Adott régen elküldött levél keresése
    - Alíz: Levél keresése csatolmány típusa alapján
    - Jani: komplex lekérdezések futtatása
    - Jani: lekérdezések ismételt futtatása
    - Jani: lekérdezéseknek megfelelő levelek automatikus továbbítása biztonsági ellenőrzésre
  - Minták és ellenminták a Piler jelenlegi interfészében
    - Ellenminta: lapos keresőlista
    - Ellenminta: A lapozó távol van a lapozandótól
    - Ellenminta: azonos keresési lehetőségek
    - Minta: előző keresések
    - Ellenminta: nincs keresésekre tárolási lehetőség
    - Ellenminta: kézi tagelés
    - Ellenminta: a spam kezelése a többi levéllel
    - Ellenminta: ismeretlen dátumformátum
- Összefoglalás
- Irodalom

Jo, csak figyelni kene, hogy nyulsz hozza...

Az van, hogy annyi idom, akarhogy sakkozom, nincs, hogy ennek a frontendjeben rendet tegyek, bar tetszoleges script kiddie-nek jo beugroprojekt.

Az MVC-t erted, ez nagyon jo, ez azert konnyebbe teszi a rendrakast, es neha mind az 5 ujjamat megnyaltam volna, ha sikerul nehany munkatarsammal ezen a szinten megertetni, pl. hogy nem rakunk logikat template-be.

Viszont 2011 -ben a tablazatokat csak tablazatokhoz hasznaljuk. Bar a result listarol meg elhiszem, hogy az tablazat, a tobbirol aligha. Ha mindenkepp tablazatszeruen akarsz _formazni_, erre a css3-nak ott a display: table property-je ( itt egy link ami elmagyarazza). IE-vel modernizr-rel tudod megbeszelni hogy mukodjenek a dolgok valamelyest, de valaki aki gyakorlottabb sitebuildben egy este alatt rendet rak ott.

Mivel a controller jol kivalaszt, valaki elolvassa a controller forrasat, es ez alapjan ki tudja mosni a template-eket siman.

Kevesellem a class-okat. Az lenne az elv, hogy mindenrol leirjuk class-ba, hogy ez micsoda, mire valo. Egyfajta objektummodellt epitunk a bongeszonek, hogy szia, figyu, ez az oldal, ez all egy keresoreszbol, egy resultlistabol... Majd a CSS-ben megmondjuk, hogy ezt hogy kell skinelni. Itt szinte mindennek id-je van csak, az is - gondolom - fokent a JS-hez. (Amit - a layout helyett - rakj ki kulon js fajlba, btw)

Ami meg hianyzik, az a frontendoldali makrok (kulonosen egy linkmakro).

Egy picit talan sokat is szamolsz a template-ekben (ugye a Parr-i template elvek szerint csak existence / boolean fuggveny kiertekeles lehet template-ben, if (szamolas < szam) nem) . Ja, es <?php print exp?> helyett hasznalj rovidjelolest <?= exp>

De controlleloldalon, modelloldalon stimmelunk, rendbe van, minden ami algoritmusos tiszta es szep, mindossze a 28 tpl fajlt kene egy max ket estes bulival rendberaknia valakinek.

De controlleloldalon, modelloldalon stimmelunk, rendbe van, minden ami algoritmusos tiszta es szep, mindossze a 28 tpl fajlt kene egy max ket estes bulival rendberaknia valakinek.

OK, mondjuk nekem lehet, hogy ez tobb estes buli lesz. De hat meg van ra 8 honapom :-) Egyelore csak annyi eszrevetel, hogy a datumot nem kell kezzel beirni, bar lehet, hanem ahogy belekattint, feljon a 'datepicker' nevu widget, pont ugy, mint a venere.com-os peldanal.

A Jani expert usernel felvetett spam problema kapcsan jelenleg azon a velemenyen vagyok, hogy azt a legjobb karantenba iranyitani, es igy bele sem kerul az archivumba. Ha az antispam szoftver (valahogy) megjeloli, es tovabbitja (es igy az archivumba kerul), akkor az kellemetlen a mi szempontunkbol, mert ahany antispam megoldas, annyifele eredmeny (=hova teszi a jelolest? subject-be vagy a header-be? Ha a subject-be, akkor hogy nez ki? Pl. [SPAM], [spam], [spam?], ... Ha egy - nyilvan spec. - egyedi headert tesz, akkor az megis mi az a header?) Azt ugyan meg tudom tenni, hogy ha pl. a subject-ben szerepel a 'SPAM' szo, akkor valoszinuleg spamrol van szo, es akkor azt halvany(abb)an irom ki, de mi van, ha pont egy fals pozitiv levelet keres? Mert ha az halvany szinnel van kiiratva, akkor azt az ember automatikusan atugorja a talalati listaban. Szoval, ha a spamek az archivumba jutnak, az kellemetlen, mert pont az esetleges fals pozitiv hiba miatt meg az sem egyertelmu, hogy torlom 30 nap mulva, es akkor Aliz sem lat a marciusi levelei kozott spamet.

A cegen beluli kommunikacio + a ki/bejovo levelek megkulonboztetese kapcsan arra gondoltam (de fixme), hogy felveszem a sajat domaineket egy listaba (ez egy ceg eseteben legtobbszor 1-2-3 domain, ami mehet a konfig file-ba telepiteskor), es a talalati listaban egy alkalmas jelet teszek a level melle, amibol kiderul, hogy ez kintrol jott vagy bentrol, esetleg egy belso levelvaltas eredmenye.

Elso korben valoszinuleg az egyszeru vs. osszetett kereses funkciot tisztazom le.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A belekattintassal az van, hogy serted az affordance elvet, nem lathato. Keress a Mystery Meat Navigstion kifejezesre, ha szerencsed van meg fent van az utjelzo tablas pelda. Ezt ugy fixalhatod, ha az ilyen inputok kapnak egy class-t, es oda egy jobbra-igazitott background-image -dzsel beraksz egy naptarikont.

Leforditva, Aliz azelott kezd el gondolkodni hogy mi a fenet irhat ide be, mielott belekattintana, amire kattint, mar ratort a frasz hogy jo lesz-e. Ne idegesitsuk feleslegesen a felhasznalot :)

A spammel az van, hogy nem minden spam amit a spamassasin annak jelol, viszont ha pont egy kritikus levelet jelolt annak amire akar Aliz, akar Jani keresne, akkor ha nincs bent az archivumba az gaz. A problemaidra a pluginezes a megoldas, az X-Spam-mittomisen mintha standard lenne, lodd be spamassasinre es tedd meg modularissa.

Most nincs nalam gep, de a finder-ben (ill. A doksiban levo finder screenshoton) nezd meg a kontextussort, oda tudsz olyat rakni hogy include spam (gmailben ez az all mailbox direktiva).

A jelzes egy jo otlet, de lehet ez filtertipus is, a komplex lekerdezes mockupnal latsz ra peldat.

Meg valami, ami fontos: Jani NEM az expert user sztereotipiaja, hanem mindazoke, akik nem a sajat levelezesuket keresik, hanem globalisan nezik a ceget. Ezek tipusesete az auditor, es elkepzelheto hogy bonyolultabb kerdesekre probalnak mrg valaszt talalni, mint Alizt.

Ill az expert userrel kapcsolatban pont a heten jelent meg egy jo cikk a smashingmagazine.com-on, "Az Expert User Mitosza" cimmel. Ezek a userek attol hogy expertek max a bevett mintakat szoktak mg jobban: Jani eppugy ketsegbeesik ha nem erti, milyen datumot farnak tole, csak kevesbe mutatja a rozsaszin meno ingjeben, nehogy meglassak rajt: neki magabiztosnak kell magat _mutatnia_.

Ill. Aliz se sikhulye, csak masra szeretne hasznalni az idejet. De Jani is minel gyorsabban szeretne vegezni, igy az expert user nem azt jelenti, hogy kaphatnak "rosszabb" feluletet, hanem pl. lehet engedni bill.kombokat, gyorsito tageket (pl. Gmailben from: esatobbi), lehet hagyni gepelni. Az expert fogalmakkal tobb, nem turelemmel,

modositottam az egyszeru kereses oldalt: http://www.mailpiler.org/screenshots-201201/search1.png

nincs benne table :-), hanem css-sel oldottam meg a tablazatos megjelenest. A lapozas felul nincs tobbe, csak alul, es ott is csak ott, ha van lapoznivalo. A datumnal ott van a naptar ikon, ill. ahogyan az korabban is megvolt, belekattintva egy widget jon fel, aho lcsak ra kell bokni a kivant datumra.

A cimkekre valo keresest (egyelore) kivettem belole, amig jobban at nem gondolom ezt a feature-t. A kereses mellett van egy "kereses mentese" gomb, amivel el lehet menteni a kereses felteteleit. A rakattintas utan pedig a jobb oldalt fent lathato legordulo menuben meg is jelenik a select-ben es 'selected' allapotba kerul.

Belepatkoltam meg a piler demonba a level iranyat (bejovo/kimeno/belso) is. Hamarosan teszek bele egy uj oszlopot, ahol ezt jelzi. Btw. hogyan lenne celszeru mutatni azt a levelet, amit x dolgozo elkuld egy kulso partnerenek, de cc-ben beleteszi a kollegajat is? Ez most kimeno vagy belso level, vagy a ketto egyutt, ill. a kozul melyik ikont mutassam az eredmeny listaban?

Ill. meg azon gondolkozom, hogy egy fokkal meg hasznalhatobb lenne a kereses oldal, ha kereses eredmenye a bal oldali hasabot foglalna el, es a tole jobbra levo resz ures lenne, amiben a konkret level jelenne meg, ha a user rakattint az eredmenylistaban valamelyik levelre.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

rendben :)

volnanak azert - nem meglepo - megjegyzeseim.

A legszembetunobb, hogy a listazas sorrendjenek megvaltoztatasat most levetted, nem kene :)

Az Alignment szabalya bar fokepp bal margokra vonatkozik, valojaban igaz a szelessegekre is: a tablazatod legyen ugyanolyan szeles mint a kereses.

Az egysegbezaras szabalyat kene alkalmazni valahol: vagy a keresesi talalatok kapjon keretet vagy mas hatterszint, vagy a keresesi feltetelek.

Ez az egysegbezaras azonban tortenhet pl. egy egyszeru vonal meghuzasaval is: ha huzol egy vizszintes vonalat a tablazat fejlecehez _sokkal_ kozelebb mint a keresogombhoz (es kihagysz koztuk masfel-ket akkora sorkozt legalabb) akkor mar jol lathato lesz.

A lapozassal se az volt a baj, hogy fent volt - jo helyen van az ott, amennyiben egy kepernyore rafer a talalati lista; ha nem, akkor felesleges nyilvan.

Itt van egy pelda:
https://dl.getdropbox.com/u/7067930/piler_ux_paging.png
https://dl.getdropbox.com/u/7067930/piler_ux_paging_explanation.png

A tavolsag es a vonal egyuttesen mar kepes egysegbezarni es ala-folerendeltsegi viszonyt kialakitani a lapozo es a lapozott kozott. Letezik ala-folerendeltsegi viszony a talalatok es a kereses kozott is, de ezt is segiti a vonal es a meretek (rendszerint az alarendelt sokkal nagyobb mint a folerendelt, az osztoneink a piramist szoktak meg. Ha egy kepernyon a keresesi feltetelek ugyanolyan magasak mint a talalati lista, akkor az emberi szemnek ertelmezesi problemai lesznek.

Ha outlook-szeru kezelest szeretnel (oldalt levellista), akkor erdemes lehet leszoknod a lapozas fogalmarol, es helyette a Continuous Scroll / Infinite Scroll patternt alkalmaznod: http://ui-patterns.com/patterns/ContinuousScrolling

Ekkor fontosak a kovetkezok:
1) a sorrendezest legalabb egy selectboxszal, de mindenkeppen fent kell tartanod
2) a usernek kell hogy fogalma legyen a talalatok osszmennyisegerol (exakt modon, magyarul ki kell irnod a lista tetejen)
3) a usernek kell hogy fogalma legyen arrol hol tart a talalatokban (ezt a scrollbar mint minta ugye koveti, minden scrollbar mutatja hol tartasz)
4) a usernek lehet nem art, hogy fogalma legyen arrol, mekkora reszaranyat latja a talalatoknak.

Magyarul implementalnod kene scrollozast, vagy trukkos modon egy ures, de nagyon hosszu divet kene csinalnod, meg bele az igazit, ami pont kepernyomagas, es kitoltogetni a tartalmat. Leteznek mindenfele jQuery pluginek erre nyilvan.

Problemam meg, hogy a masik oldalon a select box nagy helyet foglal. Erdemes elgondolkozni, hogy oda atteszed a kereses mentese gombot (amit mondjuk en csak akkor jelenitenek meg, ha mar keresett valamire), ill. hogy minimum multiselect magassagot valasztasz (tehat nem dropdown hanem scrollozhato lista)

Mittom, valami ilyesmi: http://jsfiddle.net/aadaam/C6GLh/ (nem a vilag legszebb kodja, futok, bocsi)

Itt vigyazni kell majd veletlen kattintasra, hogy ne irja felul veletlenul az epp futo keresest (window.confim pl.)

A legszembetunobb, hogy a listazas sorrendjenek megvaltoztatasat most levetted, nem kene :)

csak amig az atiras nem veglegesedik. Most 2-hoz visszatettem, a from/subject alapjan rendezes meg trukkos lesz, azt kesobb.

A tavolsag es a vonal egyuttesen mar kepes egysegbezarni es ala-folerendeltsegi viszonyt kialakitani a lapozo es a lapozott kozott.

ime a kovetkezo verzio: http://www.mailpiler.org/screenshots-201201/search2.png

Az outlook-style megjelenitesrol lemondok egyelore. Vegul is a fotogaleriaknal megszokott a jquery-s popup megoldas

kiprobaltam a select mezobol tobb elem latszodjon, de valamit elnezhettem, mert a bal oldali kereses reszt lenyomta az elemek szama-1 pozicioval.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

oke, azt gondoljuk vegig, hogy egy atlagos kepernyon hol lesz Jani es Aliz egermutatoja, amikor rajon hogy lapoznia kell, egeszen pontosan ekkor Aliz scrollozott-e mar, es mennyit. Feltetelezzuk, hogy Janinak hozzad hasonloan nagy monitorja van, Aliznak viszont a fonoke nem adott, titkarnonek minek felkialtassal, excelezni meg facebookozni jo 1280x960 is.

Ez a monitoruktol fugg, meg a mi beallitasainktol. Ha azt mondjuk, mindig annyi elemet jelentetunk meg, amennyi a kepernyore kifer, akkor soha nem kell scrollozniuk, ha scrollozniuk kell, lehet, kenyelmetlen lesz lemaszni, de a nem kell sokat scrollozni, akkor van-e okuk levinni az egeret az aljara barmikor? Ez amugy a Fitts's torveny

A Fitt torveny azt is elarulja, hogy mekkoranak kellenenek lenni azoknak a gomboknak. Feltetelezzuk, hogy amikor a talalatlista megjelenik, akkor a mutato a Kereses gombon van, es gorgetnek, majd atviszik a lapozashoz, es varhatoan eloszor elore szeretnenek lapozni. Tehat a gombok meretenek es helyzetenek a kereses gomb meretehez es helyzetehez kene igazodnia.

Aztan: nagyon fontos info nekik az, hogy mennyi az ossz kereses: ha van 540 talalat, akkor inkabb finomitanak valoszinuleg. Lehet, azt is fontos lenne kiirni, hol tartanak epp, pl. igy:


<< < 21-40, a 194-bol > >>

A pozicionalasi problemaidat blueprint css lehet tudja orvosolni.

Bevetnem tovabba a primary action mintat: http://patternry.com/p=primary-secondary-actions/ ( http://quince.infragistics.com/Patterns/Primary%20Action.aspx )

Ez alapjan egy gombnak 3 allapota lenne, elsodleges, opcionalis, es inaktiv. Itt a pelda: http://jsfiddle.net/aadaam/u7U95/

(katt keresesre)

Ez kikuszobolne a mashol irt fokusz-problemat.

Amivel surgosen kene valamit kezdeni meg az a fontok. Mondtak itt alul a typography.css -t a blueprintcss-bol, nem feltetlenul gondolom azt hogy az alkalmazastervezeshez feltetlen jo lenne, az inkabb dokumentumokhoz, de vegulis...

Ez amugy valami borzalmas linuxos klonfont lehet, mert ez se verdana, se arial, se helvetica, hanem valamifele atmenet, pici tahomas elemek is keveredtek bele, eloszor azt hittem, hogy biztos az okozza a disszonanciat hogy Verdana a tablazatfejlec, es a tobbi meg helvetica vagy arial, de nem, a CSS szerint legalabbis nem. A betukoz-osszecsuszas mindenesetre elkepeszto rondan van kirenderelve.

Sot, mi tobb, a css alapjan az input-ba beirt szovegnek tahoma-nak kene lennie, a tobbinek meg verdananak vagy annak hianyaban arial-helveticanak, de ez ugyanaz a font. Lehet csak az en szememet szurja?

Ket dolog van itt:
- A tahoma-t nem feltetlenul kene keverni az ariallal: vagy azonos betucsaladbol (font-family) valasztunk vagy masik kategoriabol valasztunk.
- A mereteknek valamifele logaritmikus skalat kene kovetnie. Lehet ez aranymetszes alapu (0.618), de igazabol barmilyen 0 es 1 koze eso szam jo, csak az a fontos, hogy ezt a skalat kovessek, pl. 0.5 eseten: 10 px, 20px, 40px...

(az Arial egy font-csalad, pl. Arial black, Arial Condensed, Arial MT stb, a sans-serif a kategoria, kozte meg van egy osztalyozasi szint, a Tahoma humanista, az Arial neo-groteszk.)

De ez csak akkor latszik, ha sikerul valami olyan bongeszot elokaparnod, ami tenylegesen megjeleniti a fontokat, nem csak beszel rola.

(Konyvben tipografiat a Tervezz Batran! erinti)

Viszont foglalkozz a funkcionalitasert is azert :) Gondolom a szabadidod veges, nekem meg kellett tanulni interfeszeket tervezni (mas nem csinalja meg civilizaltan helyettem), de egy mukodo es egy szep program kozul a mukodot valasztanam :)

a legfrissebb verzio 1280x1024-es felbontasu monitoron: http://www.mailpiler.org/screenshots-201201/search3.png

A lapozas linkek csak akkor latszanak, ha van is meg lapoznivalo (az osszes talalatok szaman meg dolgozom). A jobboldali elmentett keresesek is csak akkor jelenik meg, ha mar mentett el keresest.

A Fitt's law kapcsan szerintem kellhet az also link is (legalabbis a yahoo-nal van alul is), mert ha a user elkezdi vegignezi a talalatokat, es rakattint a linkekre, akkor szepen fokozatosan halad lefele, es egy ido utan kozelebb lesz az also lapozo sor, mint a felso.

A lapozast mindenesetre pont a kereses gomb ala tettem, bar ez mar talan tulzas, mert igy meg a bal oldali kepzeletbeli vonalhoz valo igazitas torik meg. Lehet, hogy vissza kene allitani, hogy balra zarjon: http://www.mailpiler.org/screenshots-201201/search3a.png

A tahomat kigyomlaltam, legyen minden mondjuk valamelyik Arial font? Melyik font "Linux-kompatibilis"? A font meretet majd este...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Mindkettotoknek igaza van: balra kell zarni, a next es last gomboknak kell a kereses alatt lennie!

Tehat a legelso lapra gombot a kepernyo szelehez, a legutolso lapra gombot a kereses gomb szelehez kene igazitani.

Fontos tovabba a gomb szelessege, ugye itt az a kerdes (ha elolvassuk a linkelt wikipediat), hogy a kereses gombhoz kepest mekkora az a "csatorna" amin at lehet menni, mekkora a "celterulet" merete. Szoval nagyobb kacsacsorok es/vagy finom, egeszen halvany keretezes kene oda minden lapozogombnak.

Egy levelnel mindig a from meg a to szamit, a tobbi masodlagos kezbesites. Ezert hivjak ugy, hogy "copy"

Ezt a formot en mondjuk atdizajnolnam. Ket oszlopba a kereses feltetelei, a mentett kereses alulra, a kereses mentese gombot pedig a select melle tennem. Ebbol UX szempontbol az utobbi a legfontosabb. A kereses muveletehez a kereses mentese nem tartozik szorosan oda, tehat azt a gombot a Kereses gomb melle tenni szerintem nem jo otlet. Az sokkal inkabb magahoz a selecthez tartozik.

Ezzel azt is megnyered, hogy a Kereses mentese gomb rovidebb lehet, hiszen a sor elejen ott van mar egy magyarazo szoveg, igy eleg az "Akutalis kereses mentese" feliratot raapplikalni a gombra.

Illetve egy tipp. Van egy olyan framework, hogy BluePrint CSS. Ennek keresd meg a githubos repojat, es ket CSS-t feltetlen ments le a forrasbol: a reset.css-t es a typography.css-t. Ne a honlapjarol toltsd le, hanem github repoban keresd meg a ket fajlt, a raw linkkel tudod letolteni.

A felsorolas sorrendjeben linkeld be oket, minden mas CSS elott (tehat elobb a reset.css-t).
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Alapvetoen egy pontra szeretnek reagalni, ez a kereses mentese a select mellett, hogy UX szempontbol ez a "legfontosabb", ahogy irod. En is azt irtam, tegyuk at, de vacillaltam rajt mar akkor is, es lehet hogy nincs igazad, szeretnem elmondani, miert nem, legalabbis olyankor ha hirtelen jelenik ugymond meg.

(A to: - val kapcsolatban is felig ertek egyet, alt. a to: keresesekbe bele kell "keverni" a cc-s eredmenyeket is, hisz az senkit nem erdekel, elsodleges vagy masodlagos peldanyt kapott az illeto, hanem az, hogy ment-e neki az a level; alt. nem is emlekszunk honapokkal vissza, hogy Cc-ben vagy To:-ban voltunk, vagy volt aki meg kellett hogy kapja.

Ellenben a bluegrid-et mar en is akartam irni hogy grideleshez jol jonne)

Az atrakas azert nem tuti, hogy jo dolog, mert nem fog igy feltunni, hogy van, ha hirtelen jelenik meg. Ha allandoan ott van - az ures elemet nincs ertelme menteni.

Amikor megnezunk egy oldalt, pillanatok alatt felmerjuk, es megallapitjuk, nekunk mire van szuksegunk belole, ezeket a reszeket kezdjuk elemezni.

Elkezdunk ezekre a teruletekre fokuszalni, amig meg nem talaljuk azt ami nekunk kell.

Ezutan viszont az agyunk cache-bol dolgozik.

A szem fokuszterulete meglehetosen pici, nagyjabol egy HUP-logonyi, bar ez is monitortol fugg, ugye. de egy atlagos tavolsagnal egy felcentis-centis sugaru korrul beszelunk max.

Osszes tobbi alacsony felbontassal megy, meg cache-bol egy reszletes adat-emlekkep..

Magyarul ha atrakjuk a gombot: https://dl.getdropbox.com/u/7067930/piler_ux_szuro_mentese_atrakva.png

A kedves delikvens pedig megnyomja a "kereses" gombot, nem fogja latni, toltodeskor meg mindig a baloldalon fog a szeme keringeni:

https://dl.getdropbox.com/u/7067930/piler_ux_szuro_mentese_atrakva_fove…

Ez ilyen klasszikus rendszergazda remalom, hogy nem erti, a user hogy nem veszi eszre a gombot, kinyomja a szemet, hat igy :)
Legalabbis jelenlegi tudasunk szerint (ez a szem biologiai vizsgalata alapjan tunik igy)

Ezert minden, ami nem "keznel" van, elveszik, nem tunik fel. Ezert kell mindennek a kozvetlen gombkornyezeten kivul villognia, mozognia, elenk szinunek lennie - "bannervaksag", mondanank, bar valojaban nem az.

Es igy milyen?
(Bocsass meg a minosegert, ezt a programot most hasznaltam eloszor).

Merthogy eredetileg valami ilyesmi fogalmazodott meg bennem. Annyi kitetellel, hogy azt a gombot a select melle raknam jobbra, es termeszetesen egy kicsit feltupiroznam a css-t. Csak ennyit mar nem akartam szorakozni a keppel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

sokat ragodtam mar rajta en is, de szerintem az 'elmentett kereses' szovegnek es a legordulo menunek jol el kellene hatarolodni mind a kereses gombtol, mind pedig a 'keresesi feltetel mentese' gombtol, mert imho az utobbinak inkabb a keresesi feltetelekhez van koze, hiszen eppen az aktualis keresest lehet vele elmenteni.

Szoval arra gondoltam, hogy legyen egy olyan elrendezes, mint nalad: felul 2 oszlopban a from, to, subj, date, alatta kozepen a kereses gomb, mellette mas szinnel (=secondary action) a kereses mentesenek lehetosege. Es mindezek alatt lenne egy css-ben fix szelessegre beallitott select menu az elmentett keresesek magyarazo szoveggel + opcionalisan ezt a reszt egy vekony szurke keretbe foglalnam, ezzel is jelezve, hogy ez kulon all toluk.

Igyekszem hamarosan egy skiccet is kesziteni rola, hogy mire gondoltam.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Valami ilyesmire gondolok en is, csak most nem volt idom css skeletont csinalni hozza.
az a lenyeg, hogy a gomb veletlen se keruljon a select _ala_. Ehhez az kell, hogy a selectben korlatozva legyen a megjelenites X karakterre.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

https://dl.getdropbox.com/u/7067930/piler_ux_kereses_filter_egymasban.p…

Ha mar mindenkepp ilyet akarsz csinalni, akkor a szurok felul, mert ala-fole rendeltsegi viszony...

En tovabbra is hiszek abban, hogy nem kene ket, ugyanolyan gombnak lennie egy oldalon, a Kereses-nek elhelyezkedesevel, meretevel, szinevel dominanciat kene mutatnia.

A feltetelek menteset szerintem meg lehetne oldani js-sel, kis lemez ikonnal, tooltipbe, hogy az aktualis keresest menti. Ez igy sokkal szerenyebb.

Persze itt ugye az is gond, hogy nincs igazi ertelemben vett dizajn, nincsenek dominans szinek pl, amihez egy ikont szamolni lehetne.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

mit szolsz ehhez? http://www.mailpiler.org/screenshots-201201/search4.png

A font meretek kozott 0.618-as szorzo van (12 es 19px), a font tipus arial sans-serif lett. Az osszetartozo elemek kozel vannak egymashoz, es az elmentett keresesek resz kulon kerult, igy imho nem zavar be.

A lapozas resz meg finomodik, ha az osszes talalat szama is kikerul. Egyet nem ertek: ha a text-align-nak azt adom meg, hogy 'justify', akkor miert nem huzza szet? Mondjuk ez eppen itt sem mukodik :-) http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_style_textal…

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

A narancssarga vonalak - a partpreferencias vicceken kivul - nem tudom mit keresnek ott, majd beszelhetunk szintanrol is, most maradjunk annyiban hogy az oda nem illik :) ott majd adobe kuler kell ugyis.

A sorokat megkulonbozteto szurke - meglatjuk meg, szurke lesz-e - nyugodtan lehet _nagyon_ halovany. Nem kell melle a csikozas mert megkulonboztetni, nem pedig elvalasztani akarjuk oket egymastol. Az ugyanaz a tipusu adat, ezek egy felsorolas reszei, osszetartoznak de nem akarjuk hogy egybefolyjanak.

A betumeretek egymashoz mar aranyosak, de ez nem lesz igy jo hogy az input fieldtextje masfelszerese a labeltextnek...

A kereses gomb szovege nagyon halovany. Most ezzel gyorsitott eljarasban azt tudjuk csinalni, hogy felkoverre kell tenni, tudom, az en peldamban is rossz volt, es miert utolag mondom hogy ott is vegzaltam rajta csak siettem... Sorry.

Aztan: a csikozas (meg ugy altalaban a talalati lista) erjen addig mint az elvalaszto csik, merthogy ugye errol szolna az, hogy mindket oldalrol igazitunk valamihez.

A lapozoknak kell egy parent div, szigoruan definialt magassaggal, es ami jobbra kell, az float:right, ami balra az float: left. Display:block. Ossze fognak rajt csuszkalni, that's life. Van valami inline-block, ami ezt nem-ie bongeszokben szepen kezeli, vagy lehet probalkozni padding-margin vilaggal. Ja, ill. float osszecsuszasanak megakadalyozasa: a jobbra-balra margok szuperpozicioja max(), nem sum(), tehat a ket belso gomb margojara, ha adsz nekik "rafer" a ket kulso gomb...

Haladunk, haladunk...

Akkor, kovetkezo:

- Kezdjuk irtani a szinskalat. Az egyik ez a bordo, ha jol sejtem, maradjon a bordo, rendben, de akkor az elenkpirosat ejtsuk ki, hasonlo szinek - hacsak nem veszhelyzetre felhivo utasitas (arra viszont, ha atirjuk bordora, nem hasznalhatunk majd pirosat mert az eletbe nem veszik eszre, nem tunik ki periferikus latassal)

- A primary gombok "altalaban" kekek, de ha gondolod, hasznalhatjuk a bordot, miert ne. Ha nem bordot hasznalnank, akkor egy sotetebb keket kene, de jo lesz a bordo is, rad bizom.

- Egy gombnal viszont az a fontos - ez most nem teljesul, es tudom, eddig nem mondtam, srry - hogy a jobb also sarka lehetoleg legyen sotetebb, mint a jobbfelso. Ezt itt border-left, border-top, stb -vel erhetjuk el. Kulonben ugy tunik,mintha be lenne nyomva...

(Ez amugy erdekes modon, az OS X gombjaira nem igaz azoknak az also borderjei sotetebbek leon, ugylatszik, eleg lenne egy arnyek is...)

- A keresesi feltetelek mentese es a kereses egyutt lehetne olyan hosszu, mint a keresofeltetelek oszlopa, a hely maradhat ami most van, csak keruljon a ketto koze.

A datum tol-ig -ot is hasonlokepp ki lehet huzni, de a ketto kozt ott ne legyen nagy a terkoz (inkabb nyujtsd oket picit szvsz)

A venere.com -on nincs kihuzva, http://screencast.com/t/Ukt4vfr1UrS , mondjuk nekem nem is tetszik, de legalabb egy vonal van, nem cikkcakk. A hotmail-nel egyenesebb: http://screencast.com/t/luNmD8l2uf

- Ezek a fontmeretek nekem tovabbra se tetszenek, mintha a teteje kiabalna, az aljat meg elnyomna, nem? Nezzuk meg, mi van, ha nem nagyobb a font, csak felkover? Ennyi elemet felesleges ennyire kiemelni, olyan mintha egy gittegyletben mindenki tiszt lenne, kiveve nemecseket.

Erre nezunk meg megoldast.

http://www.mailpiler.org/screenshots-201201/search6.png

btw. ha a gomb sotetebb kek lett, akkor milyen szint valasszak jobb also sarkanak (aminek sotetebbnek kell lennie)? Vagy a 'navy' mar tul sotet es inkabb ez legyen a jobb also sarok es a gomb alapszine ennel kevesbe sotet kek?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Bocs, hogy nem jelentkeztem, egyszeruen elkoltozom Londonba, es ez nem ugy megy, hogy kozbe UX-ezem is (majd fogok, holnaptol, napi 8 oraban talan...)

Na, sz'al itt egy mockup, ill. rogton 3:

https://dl.getdropbox.com/u/7067930/piler_mockup_1.png
https://dl.getdropbox.com/u/7067930/piler_mockup_2.png
(wait for it...)
https://dl.getdropbox.com/u/7067930/piler_mockup_3.png

Alapvetoen ennek mar van un. vizualis nyelve, nagyon meno dolog, sz'al lassuk is a szotarat:

1) Bordo - aktiv
2) Felkover fekete: mezonev, kulcs
3) Sotetszurke: link
4) vilagosszurke (szovegszin): inaktiv
5) keret: nyomkodhato (arnyekkal: erre van!)
6) ikon a mezoben: interaktiv mezo
7) ... a gombnevben: helyi interakcio

A vizualis nyelveknek kb. ezen a szinten kell tudniuk kommunikalni. Mondjuk nekem a T-magentarol az jut eszembe, hogy p.na, es eleg idegesito tud lenni, amikor ezt hatterszinnek hasznaljak... na mind1, lepjunk tovabb.

Ezekre vannak amugy a css class-ok!

(Elvileg amugy griddel volt tervezve, ezt egy ido utan lekapcsoltam, lehet elcsuszott, akkor bocsi)

Mint emlitettem, minimalizalni kene az egerutat, ezert van a next (ami a legtipikusabb lapozogomb) a kereses alatt. Hogy a masik hol van, hat nagyjabol ott, ahol akar, de nem japanoknak tervezunk, igy sajna balra kell tole raknunk.

Namost barhogy probaltam, sajna a betoltes es a mentes elegge osszetartozik (legalabbis akarnak), igy van egy rakas ures helyunk. Az ures hely alapvetoen nem baj - whitespace-tol felni nem szabad - viszont a kepernyon kb. nincs hely maganak a listanak a mai keskeny monitorokon, draga a vertikalis hely, igy megiscsak kezdeni kellene vele valamit.
1) ha lesz tobb mezo, akkor ket oszlop
2) a masodik oszlopot windowing teruletnek felhasznalni.

A masodikra pelda: https://dl.getdropbox.com/u/7067930/piler_mockup_1_msg_area.png

(Emlekszunk, bordo aktiv, sotetszurke link, keret katt...)

Ket oszlop eseten pedig arrebb kene tenni a kereses gombot, emiatt aztan mozog a next gomb...

Nagyon jo lenne, ha menteni mondjuk sajat nevvel tudnank, ugye ez lenne az ertelme. Defaultban felkinalhatja persze a keresesi nevet, de...

A select azert tunt el, mert akkor most mi is van a legtetejen? Ha ugyis le kell nyitni, akkor lehet gomb is.

Na, akkor lehet most emlegetni anyukamat ha nagyon muszaj...

Nekem sorrendben a 3. link nagyon tetszik, a mentett keresesek siman feljohet faceboxban is (http://defunkt.io/facebox/), annak nem is feltetlen kell helyet szoritani.
A kereses gomb egy pottyet talan nagy lett, de nyilvan ezt akarjuk a user arcaba tolni, tehat jogos.

Ami szamomra nem trivialis (sem nekem, mint hrgy84, sem nekem, mint user), hogy a felso szurke sav mire valo. Tippre lapozas es kereses, de valahogy elkivanna maganak legalabb a szovegdoboz egy labelt, placeholdert, vagy egy ikont.

Amire meg gondoltam, azok a placeholderek. Ezzel lehet peldat adni a felhasznaloknak, ezzel is segitve, hogy mi az, amire itt kereshet. A placeholderek kozos tulajdonsaga, hogy nagyon vilagos szurkevel jelennek meg, belekattintasra eltunnek, es a keresesben nem vesznek reszt. HTML5 default tudja, de egy kis kereses utan van jQuery extension is azok szamara, akik meg mindig olyan bongeszo alatt sinylodnek, amely nem kepes a HTML5 teljeserteku ertelmezesere.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Az a felso szurke sav az egy browser mockup :) nem kell megirni, minden bongeszonek van ilyenje :)

A default ertekek szerintem itt csak zajt csinalnanak, foleg hogy a szurke a masod- es harmadszin is.

A kereses gomb arcbatoloan nagy, igen, primary action. Nem tudom, eleg-e ha csak a szine mas, igy tuti hangsulyos.

Halk megjegyzes: most vettem eszre, hogy a masodik es harmadik mockupon nincs konzekvensen vegigvidve a sotetszurke = link, a lapozogomboknak es a sorrendezogomboknak is nyilvan linkszinunek kell lenniuk.

Bocs, hogy nem jelentkeztem, egyszeruen elkoltozom Londonba, es ez nem ugy megy, hogy kozbe UX-ezem is (majd fogok, holnaptol, napi 8 oraban talan...)

Nem gond, addig a projekt core reszevel haladtam. Mostmar kesz az export/backup feature :-)

A magenta szinen meg lehet valtoztatni (legyen kek, mint az echte link szin?) :-)

A mockup3 a windowing terulettel nekem jonak tunik. Kiprobalom a facebox-ot (kossz hrgy84 a tippet), de meg az is lehet, hogy a prettyphoto-t (ami a konkret levelet megmutatja) is levaltom vele.

A kereseshez tenyleg jobb lehet, ha a user ad hozza nevet (a mailarchiva is ugy csinalja)

Egy apro dolog a datum mezoknel: magyarul teljesen jo mogotte a 'tol' es az 'ig', de pl. angolul mar _ele_ kene a 'from' es a 'to'. Nagyon megkavarja a usereket, ha ezek nincsenek es csak a 2 datum mezo marad a kis naptar ikonokkal?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Figyu, ez a szin nagyjabol jo, pinkes ne legyen, most mondanam hogy hol nezd meg a kerulendo arnyalatokat, de... ;) A magenta inkabb egy ismert pelda volt mint az itteni szin kritizalasa.

(Amugy azok is csak background-kent (tehat tomeny teglalapokban) vacakok, mar persze ha nem pont az a celod vele, ezert van nehany... khm... tematikus szajtnak ilyen hatterszine)

Szineket a http://colorschemedesigner.com/ -on tudsz kivarialni ha kell, have fun :)

a -tol -ig megmondom oszinten, egy trukk volt: egyszeruen b.otthosszunak ereztem a feles date-boxokat, ha kettehuztam, tul sok volt a hely koztuk, meg valahogy akartam az elso mockup-ra egy linearis vagy negyzetes, esetleg logaritmusos elt a balra igazitasokban, viszont nem teljesen felboritva a rendet, igy ezzel az okosleany-megoldassal krealtam egy ivet (mezovegek + kereses gomb).

Nyilvan az okosleany-megoldasokkal az a baj, hogy igazabol hekkek: ez vizualis hekk, semmi tobb, adott helyzetben mukodik, valtoztatas eseten omlik ossze... Amugy a tiedre az elvi megoldas a field-template lenne ( "from %s to %s", "%s -tol %s -ig"), de mondom, ez igazabol trukk, bocsi.

Vigyazz arra, hogy mi okoz page-valtast, es mi ajax-ot, a usernek nem mindig mindegy (a page-valtasnal felkeszul arra, hogy most megeroszakolja a turelmet, mert az emberi agy turelmi hatarideje 100 ms es 1 mp kozott van, 1mp felett a kisagy mar reg qrvaanyazik)

jelenleg itt tartok: http://www.mailpiler.org/screenshots-201201/search7.png

fent valtozott a menu, amert az admin user 2-vel tobbet lat a fenti menuben. Ez, gondolom megneheziti, hogy a https://dl.dropbox.com/u/7067930/piler_mockup_1_msg_area.png mintajara a Kerese + Osszetett kereses + Beallitasok harmas a menuben a baloldali kereses oldalaihoz igazodjon...

A lapozas javitva van, kiirja az osszes talalatok szamat is.

A szinek kapcsan arra gondoltam, legyen a lapozasnal megkulonboztetve a kattinthato (ez amugy nem pink lenne szandek szerint, hanem bordo: #850505) es a nem kattinthato (#3d3d3d). Ezert a keresesi eredmeny reszben is linkszinu lett a kattinthato subject, igy vegul is konzekvens a link vs. nem link szotar egyet kiveve: a menu nem aktiv (de kattinthato) linkjei. Ezeket hogyan kellene modositani ugy, hogy nyilvanvalo legyen, azok is katinthato linkek? Vagy az ranezesre nyilvanvalo, hogy az ott a menu, es mindegyik elem kattinthato? Mondjuk igy van kontraszt (bordo vs. fekete) a menuben a kivalasztott (=rakattintott) es a tobbi menu elem kozott.

A kijelentkezes atment jobb oldalra. Meg a kereses folotti menut megprobalom a kereses oldalaihoz igazitani estefele.

Btw. megneztem a szinkevero oldalt, es egyet hamar kideritettem: en khmmm... masban vagyok tehetseges :-)

Kerdes: az elmentett keresesek betoltese hogyan nez ki (ugy ertem, mit lat a user), ha rakattint a gombra? Ez egy ajax-os autocomplete megoldas lenne? Vagy egy tobb elem magas select?

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Elorebocsatok egy kerest: nyissunk a kovetkezo bejelentesnek egy uj szalat. Ez mar hosszura nyult, es laptoprol egyre nehezebben olvasom.

Szerintem egyebkent nem neheziti meg. Reszben annyira nem gaz, ha a jobb szele nem igazodik a kereses oszlophoz, hanem a masik oszlop jobb szelehez igazodik, reszben pedig ha kell meg ful, akkor kell meg ful, pont.

A Kijelentkezes menuhoz legalabb a jelenlegi user nevet ki lehetne irni? Vagy legalabb a nickjet?
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Meg erre reagalok aztan nyithattok.

A kereso a baloldalon nem tudom, mit csinal, az ilyen advanced valami?

A filterezes attol fuggoen lehet ajaxos vagy sima magas select (akar a ketto otvozete, keresheto lista) hogy mennyi van belole. Ha megcsinalod keresheto magaslistanak, az olyasmi mint az ajax autocomplete azzal a kulonbseggel, hogy ures ertekre az osszes letezo filtert mutatja.

A kereses gomb legyen magasabb, ne nojon ossze a mentessel, cserebe mindket oldalon lehet keskenyebb (igazodni margoval is lehet)

Az oda-vissza lapozasban ha mar igy szinezunk akkor inkabb forditva, valamint a visszafele irany lehet szurke (mint ahogy a Mentes gomb se elerheto, ez se az ha nincs hova visszalapozni...)

Lehet egy em -mel tobb terkoz a kereses gomb es a lapozas kozott vertikalisan...

Amugy velemeny?

Altalanos termekben sosem ajanlott a rovid jeloles hasznalata, mert nem tudhatod, milyen kornyezetben fogjak hasznalni. Nem veletlen, hogy nagyjabol egyik nagy CMS vagy szoftver sem alkalmazza, a legtobb amit lattam ebben a kontextusban, az a Smarty bevezetese volt.
Foleg egy biztonsagi termeknel fontos, hogy lehetoleg minel fuggetlenebb legyen a futtato szerver beallitasaitol, es csak minimalis php core beli beallitast koveteljen meg maganak.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

De annyi mindent kell ehhez a rendszerhez amugy is feltelepiteni, es egy makroval is altalanosithatja (build). Jo, ekkor stallmani ertelemben nem lesz nyilt forraskodu, de a forraskodnak nem az a dolga, hogy jol jarjon az interpreter hanem hogy el lehessen olvasni hogy mit akar csinalni, erre ez a forma nem alkalmas (a smarty meg ha nem jol configoljak a rendszert vicces lyukakat hagy vagy durvan lassit).

Szoval itt ez nem a belastudio kft honlapja, ez valoszinuleg kemenyen dedikalt rendszeren futo dolog, ide szvsz lehet, de ez egy szakmai velemeny, az is valid allitas hogy smartyzzon, meg az is hogy irja ki akkor is ha olvashatatlan tole a template, nekem az a stanszom, hogy roviidtesjel ebben az esetben indokolt.

De teny, a tablazat-kiirtas, a linkmakrok, a tul sok feltetelszamolgatas fontosabbak lennenek, nagyjabol ebben a preferenciasorrendben, ez egy masodlagos megjegyzes volt.

A fo php.ini-ben torteno turkalast nem illik makroval altalanositani. Mivel nem mindig modulos PHP-val futtatjak ezeket a stuffokat, fel kell keszulni arra, hogy nagyon fognak nyekeregni a rendszergazdak, ha valamit allitani kell a php.ini-ben.

Megmondom oszinten, en is felszisszenek, ha valami webapp miatt a php.ini beallitasokhoz kell nyulnom. Teszem hozza rogton, hogy az en szervereimen a short_open_tag egy engedelyezett feature, mert neha (nagyon neha...) en is hasznalom. De masnal esetleg szigorubb a policy, es nem engednek core feature-ket allitani.

Ehh, mindegy, tudom, hogy velem az a baj, hogy en mindent uzemeltetesi szempontbol nezek, meg nem tudok orulni semminek se. :-)
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Hat en ugye alt. telepitett rendszereket fejlesztettem, ott ez nyelvi ficsor, beallitod, hasznalod, kesz. Jobban szerettuk mint a smarty-t, mert ott ilyen opcioid vannak:
- interpretalja - nyilvan lassu
- runtime konvertalja PHP-be - nem kell elmondani, mitol lassu
- elso futtataskor legeneralja PHP-be, es elmenti valahova - ekkor a legeneralt fajlokra "vigyazni kell", nehogy ...mas... valtoztassa meg oket

Ehhez kepest rogton PHP-be interpretalni gyors, hisz pont erre volt eredetileg kitalalva, template nyelvnek.

Egy string kiirasanal mindegy, hogy <?= vagy <?php print. A PHP attol template nyelv, hogy ami nincs <?php tagek kozt, az 1:1 kitolja. Nyilvan a template nagy reszet nem szabad kiechozni, csak a valtozo reszeket.

Nekem folyamatosan az a nyugom, hogy ez egy opensource szoftver. Jon a rendszergazda, letolti, felrakja, szuper. Mivel nem fizetos stuff, nincs hozza support, etc, igy csak a rendszergazda johiszemusegere lehet hagyatkozni.
Ha ez egy closed, fizetos cucc lenne, akkor neked lenne igazad, jon a support, jol megmondja, hogy a szoftverre igy van tamogatas, es csokolom. De ez ebben az esetben nincs, es a szoftvert talan pont emiatt nem fogjak a potencialis vevok valasztani, mert kvazi "bele kell nyulni a rendszerbe".

En nem vagyok ennyire haklis, egy bezart dobozban vigan futhat, kart nem tud csinalni. De el tudom kepzelni, hogy nalam kevesbe rugalmas emberek is vannak rendszergazdai pozicioban.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nekem folyamatosan az a nyugom, hogy ez egy opensource szoftver

???

Mivel nem fizetos stuff, nincs hozza support,

ez nem igy van, ehhez _lesz_ kereskedelmi support (ha a majdani levlistat, forumot, whatever nem szamitjuk).

Ha ez egy closed, fizetos cucc lenne, akkor neked lenne igazad, jon a support, jol megmondja, hogy a szoftverre igy van tamogatas, es csokolom.

Nem ertek egyet. Mivel ez jellemzoen egy erre a celra dedikalt kornyezetben fog futni (nem pedig 200 masik dolog mellett), ezert siman elo lehet azt irni a telepitesi leirasban, hogy 'a php-t igy es igy allitsd be'.

De ez ebben az esetben nincs, es a szoftvert talan pont emiatt nem fogjak a potencialis vevok valasztani, mert kvazi "bele kell nyulni a rendszerbe".

De van/lesz tamogatas, es nem 'belenyulni' kell, hanem a szoftver kovetelmenyeinek megfeleloen beallitani a kivant dolgokat. Ez amugy nem feltetlen az ordogtol valo, mert adott esetben pl. egy kereskedelmi szoftver is kerheti azt a telepitoben, hogy allitsd be pl. az shmem-et ennyire meg ennyire, vagy a php.ini-ben allitsd be a memoria limit erteket, stb.

De el tudom kepzelni, hogy nalam kevesbe rugalmas emberek is vannak rendszergazdai pozicioban.

Egy telepites vegrehajtasa (mondjuk egy step-by-step howto alapjan) nem tudom, mennyi 'rugalmassagot' igenyel. Szerintem 2-3 valtozo beallitasa a php.ini-ben (mondjuk 1 perc munka, ha nagyon keresni kell) szerintem nem nagy ugy.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Hat, en el tudom ugy kepzelni, hogy ez egy kisebb cegnel mondjuk a backup gepen fog futni (tehat, ami a backupokat is vegzi), szoval az, hogy mi mennyire dedikalt, az ne feszegessuk.
Ha lesz hozza kereskedelmi support, az persze mas, azt hittem, hogy ez csak plain opensource stuff,

Mindazonaltal, nyugos az, ha nem a php default telepitesevel szamolsz. Mi van, ha a kovetkezo verzioban ugy dontenek, hogy nincs short_open_tag? A jelenlegi fejlesztesi modelljuk (khmm...) mellett ez teljesen realis kerdes. Long-term supportnal az a jo, ha minel kevesebb hibalehetoseggel kell szamolnod. Ez jobb neked, mint fejlesztonek, jobb a supportosoknak, jobb az ugyfelnek.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Szép munkát végeztél. Számomra nagyon érdekes volt, hogy sok olyan dolgot olvastam aminek nem tudtam a nevét, vagy hogy ez egy szabály csak zsigerből úgy csináltam. Például a munkahelyemen mi is datepickert használunk és itt is a belekattintós módszer volt, de én úgy éreztem, hogy a felhasználónak valahogyan a tudtára kell adni, hogy ez nem egy egyszerű text field, ezért oda raktam egy kis calendar icont. Szerintem sok minden abból amit leírtál az "ráérzés", érzék kérdése, de ugyanakkor simán tanulható is.

A probléma az szokott lenni (és néha nalunk is ezt látom), hogy aki igazán jó a business logic/backend fejlesztésében az a frontendnél szörnyű dolgokat művel.. :)
Illetve még mindig isszuk a levét a régi táblás berögződésnek.

Lentebb írtad:

"Kevesellem a class-okat. Az lenne az elv, hogy mindenrol leirjuk class-ba, hogy ez micsoda, mire valo. Egyfajta objektummodellt epitunk a bongeszonek, hogy szia, figyu, ez az oldal, ez all egy keresoreszbol, egy resultlistabol... Majd a CSS-ben megmondjuk, hogy ezt hogy kell skinelni. Itt szinte mindennek id-je van csak, az is - gondolom - fokent a JS-hez. (Amit - a layout helyett - rakj ki kulon js fajlba, btw)"

E mellé még szeretném megjegyezni, hogy sokan nagyon sokszor indokolatlanul használnak div tageket illetve, rossz helyen használják azokat és keverik azt is, hogy hol kell inline és box elemeket használni. A class-ok nagyon fontosak de talán az még beszédesebb, ha olyan beszédes html tageket használjunk az adott helyen ami oda illik és tényleg azt a feladatot látja el.

Pl: Ha van egy "címed" akkor nem berakod span tag-be és után félkövérré formázod és megnöveled a betűméretet, margin-t, hanem például h1 tag-ot használsz.

Kötelező olvasmány:
http://dev.opera.com/articles/view/1-bevezeto-a-webes-szabvanyokba/

Hasznos lehet:
http://www.w3.org/TR/CSS2/selector.html#pattern-matching
http://weblabor.hu/cikkek/cssalapjai1
http://www.hotdesign.com/seybold/everything.html

Kis szórakozás:
http://lohere.net/ikm/index.php/Webdesign

ui: Érdekesség, hogy mikor bemutatsz egy munkát egy hozzá nemértő személynek, akkor egyből a részletekben fog elveszni...
"Miért van ez oda igazítva?"
"Ez miért félkövér?"
"Ez a gomb miért zöld?"

Tehát nagyon fontos az első benyomás, az hogy a programod kinézzen valahogy, legalább olyan fontos mint hogy jól működjön. Természetesen írd meg az alsóbb rétegekhez tartozó kódot, de utána mindenképp csináld meg a CSS design-t is és a html layoutot is. Mert, hogyha van két program és az egyik kicsivel kevesebbet tud, de sokkal jobban néz ki (könyebben érthető, kezelhető), jobb első benyomást tett a főnökre, akkor azt fogják választani és még csak okolni sem lehet őket, mert ez nem tudatos választás lesz hanem belülről jön majd.

Egyébként én néha legalább annyira élvezem a layout-al való bohóckodást mint a tényleges kódolást. Mert ott is ki lehet élni alkotói vágyunkat.
Felhasználói szemmel nézve a GUI-dat még elég sivár, de lesz ez még jobb is. Sok ötletet tudnék még (szeretnék) adni, de most épp munkaidőbe vagyok.. :)

Csak pár példát említve:
Táblázatot jól fel lehet dobni "even odd-al", persze nem piros kék háttérrel, hanem valami lightos árnyalattal.
Szerezz be valamilyen igényes icon szettet, mert azt imádják ha van icon és néha beszédesebb is mint a gombok. Ha így teszel azért mindig rakj a képnek title-t, hogy ha felhasználó fölé viszi az egeret akkor tudja miről van szó.
Ha a felhasználó valamilyen tevékenységet végezz, jelezz neki vissza, hogy tudja mi van, ezt teheted popup-okkal vagy egy ízléses message csíkkal a header alatt.

Amúgy a desgin-al kapcsolatban, szerintem nem szégyen ha megnézel más oldalakat is, mert onnan lehet venni ihletet, mert tényleg nincs új a nap alatt már. De ez szerintem nem lopás. Nem azt mondom, hogy szedd le egy oldal CSS kódját és egy az egybe vágd be, hanem ha valami megtetszik azt másold le és formáld a te oldaladhoz, építsd bele.

szerk: Nem tudom használsz e firebugot, de design-hoz és js-hez elengedhetetlen. A chrome és az IE beépített változata vacak az fb-hez képest.

Nem lebecsulve a tehetseg es kreativitas erejet:

Azt gondolom, a tehetseges ember ontudatlanul mintakat ismer fel es alkalmaz. Az egy problemaminta, hogy a datummezorol nem tudni micsoda, ennek egy lehetseges megoldasa a datepicker.

Hasznos mintakban kommunikalni, mivel elvonatkoztat, es epito tud lenni. Ez nem jelenti azt, hogy a szemelyes preferenciaim ne keveredhetnenek bele, de objektivebbnek hiszem mint a "nemteccik"-et.

Azt is gondolom, hogy egy helyes kialakitasu oldalt esztetikusnak talalunk, kulturatol fuggetlenul.

Bar kerulom a div-tulhasznalatot, azt gondolom, a "joker" elem hasznalata kevesbe baj, mint egy hibas elemhasznalat (table)

Nyilvan a mintakban mas oldalakat neztem, hasznaltam referencianak, ettol minta, hogy mashol is elofordul, ismetlodik.

Bar a paros-paratlan sormegkulonboztetes nem rossz otlet, ez pusztan az egyik modja ennek, meglatjuk, ide melyik vizualis segedlet passzol majd leginkabb.

aki igazán jó a business logic/backend fejlesztésében az a frontendnél szörnyű dolgokat művel.. :)

sohaj... :-) de a jo logic/backend fejlesztot magamra vettem :-)

Egyébként én néha legalább annyira élvezem a layout-al való bohóckodást mint a tényleges kódolást. Mert ott is ki lehet élni alkotói vágyunkat.

nalam a napokban a "haladunk-haladgatunk" filing valtakozik a "jaj, meg mi jon elo?!"-vel. De hadd jojjon elo, mert ha a motorhazteto alatt szepen berreg is a dolog, de azert nezzen is ki normalisan. Ugyhogy (kis tulzassal elve) Aadaam kinyomtatott hsz-eivel vettem korbe magamat :-) De a tobbiek segitseget is ertekelem, pl. a fentebbi linken mar valtakoznak a talalati lista hatterszinei.

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Mit akarsz, a piler eleve jobban nezett ki mint amennyit az atlaghupper ossze tudna hozni magatol, es a html-css-evel se volt akkora baj mint szokott lenni.

Az ilyen UI-tisztitasok meg spike-okba szoktak jonni, nincs tokeletes UI csak olyan amit eleget csesztettek epp most :)

Es a funkcionalitas az elso mindig.

Hat, ha valaki kiszur mondjuk egy memory leaket, akkor nem feltetlen, de ez az en privat velemenyem volt.

En azt szoktam csinalni, hogy amikor mar van egy futo verziom, akkor feltolom egy repoba az egeszet, es beleirom a README-be, hogy under active development. Ilyenkor nagy altalanossagban az emberek a helyen kezelik a stuffot, vagyis legfeljebb javasolnak dolgokat. De neha az is hasznos am...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Oppsz, errol a valaszrol csak siman lemaradtam. Ne a targz-t rakd fel, hanem hasznalj valami forraskod hosting megoldast, azt mindenki konnyebben hasznalja. Ha a git-et ismered, akkor a GitHub tokeletes hely lehet...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Vallalati kornyezetben talan a Symantec Enterprise Vault a leghasznalhatobb erre a celra, de az is egy rakas sz@r sajnos, szoval tamogatom az elkepzelest!

Ha megirnad Exchange-dzsel integralhatora (pl az lehetne a fizetos resze) akkor nagy kiraly lehetnel, mert jelenleg _nincs_ hasznalhato mail archiving termek a piacon.

http://msunified.net/2010/11/16/archiving-in-exchange-server-2010-vs-sy…

Ebben az esetben csak enduser vagyok de userkent baromi idegesito, hogy pl nem tudok az outlook nativ keresojevel keresni a regebbi mailekben - csak kulon feluleten. OWAn keresztul pedig pl nem lehet visszarantani a leveleket a Vaultbol.

Gyakorlatilag arra lenne szukseg, hogy a user szamara transzparens modon kezelheto legyen a letarolt email is.

az elso korben biztosan nem lesz outlook plugin/integracio (ez nem volt benne a palyazat vallalasaban), csak webes eleres. Ha minden core feature popecul mukodik, akkor osszegyujtom a tovabbi igenyeket, aztan meglatjuk. De egy fel even belul kevesse realis, hogy az outlook feature-nek neki tudok allni, mindenesetre felirtam ezt az igenyt.

Btw. valami ilyesmire gondolsz?

http://www.mailstore.com/images/screenshots/server-v6-en/outlook.jpg
http://www.mailstore.com/images/screenshots/server-v6-en/outlook-search…

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Jól néz ki. Csak hogy jól értem-e... Ez valami olyasmi, mint a Barracuda Spam Firewall?

Internet -> levél jön -> Barracuda (spam és víruszűrés + helyileg tárolja a leveleket megadott ideig, majd löki tovább a megszűrt leveleket) -> mailszerver

A másik: az ilyen rakd össze megoldásokkal sokaknak az szokott a baja lenni, hogy nehéz számukra a telepítést végigszenvedni. Mennyire bonyolult összehozni? Esetleg van/lesz belőle valami "kész" megoldás (virtuális gép appliance, telepítő ISO stb)?

Vagy ha erről vannak infók, akkor azokat hol lehet megtalálni?

--
trey @ gépház

Jól néz ki. Csak hogy jól értem-e... Ez valami olyasmi, mint a Barracuda Spam Firewall?

Nem, ez olyan, mint a Barracuda Message Archiver: http://www.barracudanetworks.com/ns/products/archiver-overview.php
A piler nem foglalkozik spamszuressel, bar opcionalis(an bekapcsolhato) virusszures van benne, hogy (ismert) malware ne keruljon az archivumba. Viszont, ha a jelenlegi antispam megoldasod tud olyat, hogy a levelekrol egy masolatot egy bizonyos cimre tovabbit (ha nem, akkor a mail szerverednek kell ezt tudnia), akkor a piler konnyen berakhato barhova, mert smtp-n tudja fogadni az archivalando leveleket.

A másik: az ilyen rakd össze megoldásokkal sokaknak az szokott a baja lenni, hogy nehéz számukra a telepítést végigszenvedni. Mennyire bonyolult összehozni?

Nem veszes. A wiki gyakorlatilag meg ures, de lesz benne egy step-by-step leiras is, ahol 1 oldalon minden le lesz irva, ami az indulashoz kell, hogy pl. debian 6.0.x alatt hogy lehet egy ilyet osszedobni. Telepito iso-rol lehet szo kesobb (bar felek, hogy mindig pont az a disztro nem lesz, amit eppen keresnek), de egy vmware image nagyon sanszos (a jelenlegi tesztkornyezetem is ilyen), ill. gondolkozom meg egy demo site-on is (preferaltan egy dedikalt vps-en futtatva), ahol ki lehet probalni, hogy mit tud.

Vagy ha erről vannak infók, akkor azokat hol lehet megtalálni?

Meg nincs, de 1-2 heten belul remelem, hogy fel tudom tolteni a wiki-t, es akkor mar lesz ertelme kirakni a tar.gz-t is. Ez az iras csak egy statusz riport, ill. lehetoseg, hogy megkopkodjek az eddigi eredmenyeket, es elmondjak, hol merre kell modositani, hogy nekik jo legyen.

Amikor a doksi es a tar.gz is osszeall, akkor irok egy ujabb cikkturkalos irast, hogy lehet tesztelni. Meg az iden szerettem volna eljutni idaig, de karacsonyra mar nem lesz meg :-)

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Bár nem ismerem az IMAP lehetőségeit, de az átlag bölcsész user számára a "küldd tovább erre a címre ezzel az smtp szerverrel" megoldásnál (ha jól értettem az archiválás menetét felhasználói szemmel) egyszerűbb lenne a "húzd a levelet ennek a fióknak a mappájára" megoldású (az arhiválási helyet imap fiókként használó) megoldás.
Nincs lehetőség arra, hogy imap-pal lehessen belepakolni a leveleket?

Bocs a belevau miatt, ha meg hülyeség, jelezzétek, a szemléletszélesítés mindig hasznos számomra is.

igen, ahogy tompos is irta, ez nem user oldalon futo megoldas, hanem (preferaltan) egy dedikalt gep, amire automatikusan mennek a levelek masolatban. Az nem jo archivalas, ami a userre var, hogy legyen szives belepakolni a leveleket.

Az imap amugy nem lehetoseghulyeseg, az 1.1-es verzioban valoszinuleg lesz egy 'imap source' beallitasi lehetoseg. Azt hiszem, pont az exchange tud ilyet, (de fixme) ahol egy journaling account-ot is be lehet allitani, ami az osszes account osszes levelet tartalmazza, igy eleg ezt az 1 imap acc-ot lekerdezni. Mondjuk kerdes, hogy a kimeno levelek is benne vannak-e...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

Szép munka! Gratulálok, és kitartást a folytatáshoz.

Érdemes volt ezt a projektet beválasztani a pályázaton, úgy látom, hogy nem fogsz csalódást okozni. Csak így tovább. :)

haladtam egy kicsit a core feature-okkel, es most a levelek integritas ellenorzese van soron. Ez a hsz amolyan hangosan gondolkodas, ill. brainstormingra felhivas.

Az egyes levelekhez kulonfele metaadatok tartoznak, pl. meret, felado, datum, digest, stb. Minden levelhez eltarolok egy ellenorzo digest-et, ami az elobbi adatokbol all elo. Ennek az a funkcioja, hogy ellenorzi, hogy a level valoban ugyanaz-e, mint ami a beerkezeskor es archivalaskor volt.

Ez a paranoia fokatol fuggoen lehet eleg vagy eppen keves. Egy rosszindulatu es elszant rendszergazdatol ennyi meg nem fog megvedeni, aki full root hozzaferessel akar modosithatja is a leveleket, majd az ellenorzo hash-eket is az algoritmus birtokaban (ami egy nyilt forrasu termek eseten nem titok).

Egy masik topikban mar toprengtem egyet a probleman, es az alabbi 2 megoldas johet szoba:

a) minden egyes levelhez tartozo ellenorzo digest-et nem csak az adott level metaadataibol allitom elo, hanem beleveszem az elozo 2 levelhez tartozo ellenorzo digest-et is. Igy egy adott levelet nem lehet ugy modositani, hogy az utana kovetkezo leveleknel ez ne bukjon ki.

b) minden oraban kigyujtom a levelek ellenorzo osszegeit, egy digest-et keszitek belole, majd alairatom egy kulso 3. fellel.

Az a) hatranya, hogy nagyobb forgalmu site-on race condition allhat elo, azaz mivel tobb processz is irja a metadata tablat, ezert siman elofordulhat, hogy az x-dik level ellenorzo osszegenek elkeszitesehez meg eppen fut az sql select, amikor mar beesik az x+1-dik level is, es lekerdezi az x-dik level ellenorzo osszeget a sajatja eloallitasahoz, de az x-dik levelnel meg NULL van, igy az x+1-dik level ellenorzo osszege hibas adaton alapul, ami boritja a koncepciot.

Megoldas lehet az, ha egy kulso processz kesziti el az ellenorzo osszegeket, igy nincs race condition, de ez nem valami elegans, es bonyolitja a kepletet. Bar egy pl. 5 percenkent futo cron script akar meg beleferhet.

Viszont tovabbra is kerdes, hogy a gyakorlatban hany levelnyit kell visszamenni, es ellenorizni, hogy meg ott is jo-e az ellenorzo osszeg (emlekszel: lancban vannak az ellenorzo osszegek).

A b) megoldas hatranya, hogy egy "korrekt" TSA szolgaltato nem puszira adja a belyegeket, hanem azert bizony penzt kell csengetni, ami egy koltseghatekony helyen szempont lehet. Mondjuk kerdes, hogy nekik valoban kell-e ilyen foku paranoia. Mert pl. egy penzugyi cegnel sanszos, hogy igen, de ott valoszinuleg meg van ra a penzugyi keret is.

Szinten a b) megoldas ellen szol, hogy egy adatcsere a TSA szolgaltatoval (protokoll szinten) azert nem trivialis. Az openssl tamogatja ezt (de csak az 1.x-tol kezdve) ugy, hogy cmd line kell ugyesen felparameterezni (mert API-bol nem tamogatja ezt a feature-t), es hadd szoljon, ami azert finoman szolva nem ugyes megoldas egy C-ben irt program eseten. Itt is ugy lehet ezen a banto ponton enyhiteni, ha pl. egy cron script vegzi az orankenti belyegzest.

Viszont nem csak kereskedelmi TSA-k vannak, hanem free "belyegzok" is, pl. http://ecrive.net/. Ezeknel a koltseg nem szempont, viszont cserebe semmit nem garantalnak (pl. SLA, az idobelyeg idejenek pontossaga, megvesztegethetetlenseg, stb.)

Szoval azon tunodok, melyik utat valasszam: a), b) esetleg c)? Egyelore a b) megoldas tunik szimpatikusnak az ecrive (vagy mas) free TSA szolgaltatoval. Az is megfordult a fejemben, hogy csinalok en magam egy "free TSA"-t, de a felmerult dilemmak vs. garanciak ebben az esetben sem tunnek el, sot egy fokkal tan meg erosebbek is lennenek...

Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara

"ugy, hogy cmd line kell ugyesen felparameterezni (mert API-bol nem tamogatja ezt a feature-t)"
Mivel az OpenSSL is C-ben van irva, itt valoszinuleg annyi a teendo, hogy ki kell lesni a kodbol, hogy mit hasznal, es azt kell neked is hasznalni. Osszerakod egy C fajlba, csinalsz egy wrapper fuggvenyt, es koszonjuk.

Ami a dilemmat illeti: en elmennek egy olyan megoldas fele, hogy ket opcio lenne: levelenkenti digest, vagy TSA. Ahol koltseghatekonynak kell lenni, ott ugysem kell uberszuper biztonsag, oda eleg lehet a digest, ahol meg a biztonsag extrafontos, ott meg ki fogjak csengetni a TSA koltsegeit.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ime a jelenlegi allas, benne van a felhasznalo neve is: http://www.mailpiler.org/screenshots-201201/search8.png

a meg hatralevo feature-ok:

- osszetett kereses implementalasa (webfelulet + a tenyleges feature)
- archivalasi szabalyoknak (=mit NE archivaljon) egy kattintgatos weboldal keszitese
- retention policy-nek egy kattintgatos weboldal keszitese (+ a tenyleges feature)
- 'hold email' funkcio (ha ez aktiv, akkor senki nem torolhet levelet az archivumbol)
- (valamilyen) TSA tamogatas
- kereses az audit rekordok kozott
- tag-eles atgondolasa*

*: sokat toprengtem ezen Aadaam pdf-et elolvasva. O azt javasolta benne, hogy cimkezni lehessen a kereses osszes talalatat. Azonban szerintem ez igy nem jo, mert kevesse sanszos egy olyan kereses, ami csak olyan talalatokat ad vissza, ami mind erdekel minket. Szoval lehet, hogy marad a jelenlegi formaban (az uzenetre kattintva lehet cimkezni az adott levelet), vagy ha azt mondjatok ez a cimkezes dolog eleve nem jo otlet / folosleges, mert magat a keresest is el lehet menteni, ami aztan a kesobbiekben is szallitja ugyanazt a talalati listat, akkor lehet, hogy megprobalok egyezkedni az fsf.hu-val (a leendo felhasznalok igenyeire tamaszkodva :-)), hogy csereljuk be ezt egy masik feature-re, pl. a levelek pop3/imap forrasbol importalasa. Jelenleg a piler (a cli importot nem szamitva) csak smtp-n kepes fogadni a leveleket, de eme feature-rel pl. a gmail-bol is be lehet vonni a leveleket az archivalasba, ill. az exchange-ben is megoldhato ez, hogy az osszes email egy journaling account-bol elerheto legyen - imap-pal...

a kovetkezok szinten szerepelnek a tervekben (a varhato elkezdesi idejuket egyelore a kodos jovobe teszem):

- outlook plugin (sanszos, hogy ez lesz kesz legutoljara, ha egyaltalan...)
- vmware image-ben egy eloretelepitett installacio (megprobalom a hovd linux eredmenyeit figyelembe venni :-))
- worm drive tamogatas

Palgium

A kereso a baloldalon nem tudom, mit csinal, az ilyen advanced valami?

Arra celzol, hogy a "Kereses" kiment teljesen balra, az input mezok vonalan tul? Vagy megis inkabb a jobboldali egyetlen input mezorol van szo a nagyito ikonnal? Ha az utobbi, akkor az lesz az elmentett kereseseket elocsalo resz (de meg nincs kesz). Azon gondolkozom, hogy lehet elkelne egy hatarolo vonal a menu es a kereses input mezok kozott, mint ahogyan a lapozas es a talalatok kozott van, segitve a szemnek, hogy itt kulonbozo dolgokrol van szo.

A filterezes attol fuggoen lehet ajaxos vagy sima magas select (akar a ketto otvozete, keresheto lista) hogy mennyi van belole. Ha megcsinalod keresheto magaslistanak, az olyasmi mint az ajax autocomplete azzal a kulonbseggel, hogy ures ertekre az osszes letezo filtert mutatja.

OK, vagom, hamarosan meglesz.

A kereses gomb legyen magasabb, ne nojon ossze a mentessel, cserebe mindket oldalon lehet keskenyebb (igazodni margoval is lehet)

Az oda-vissza lapozasban ha mar igy szinezunk akkor inkabb forditva,

Oooo, ezt nem ertem...

valamint a visszafele irany lehet szurke (mint ahogy a Mentes gomb se elerheto, ez se az ha nincs hova visszalapozni...)

ez a szinezes mar csak holnap...

Lehet egy em -mel tobb terkoz a kereses gomb es a lapozas kozott vertikalisan...

megvan

Amugy velemeny?

Most itt allok: http://www.mailpiler.org/screenshots-201201/search9.png

Amugy szerintem egyre jobb (a topiknyitoban lathatonal fenyevekkel), es lassan atterhetek az osszetett keresesnek a dinamikusan bovitheto felteteleire.

Palgium

Én még mindig tartozom neked a logótervekkel. Ne haragudj, sajna túlvállaltam magam az utóbbi időben és több tervet elvetettem, mert nekem sem tetszettek. Újra nekiállok nemsokára. Teljes design ötletem még nekem sincs, de agyalok azon is hátha :)
--
AGA@
Fork portal és az egyik logóm :)

Az a jobboldali az a Betoltes gomb nyomasaval lenne csak lathato am.. ha allandora akarod tenni, akkor vedd le a Betoltes gombot.

A Datumnal egy pici helyet hagyhatsz a ketto kozott.

Most jo helyen van a lapozasnal a piros, elotte a visszagomb volt piros ami az elso oldalnal nem mukodik... vagy lehet nem az elso oldal volt?

Hogy jobb-e... remelem... meg kell kerdezni a felhasznalokat.

Meg azon gondolkozom, hogy lehet elmagyarazni a felhasznalonak, mibe kell beleirnia elso alkalommal, de valoszinuleg ha nem lesz se keresesi talalati lista, se betoltheto filterek listaja, rajon magatol... ha meg defaultbol listazunk mindent, akkor talan ha kevesbe hangsulyos a fejlec, akkor rajon :)

Az a jobboldali az a Betoltes gomb nyomasaval lenne csak lathato am..

ez igy is van, a screenshot azt mutatta, hogy Bela betoltotte az elmentett kereseseit.

Meg azon gondolkozom, hogy lehet elmagyarazni a felhasznalonak, mibe kell beleirnia elso alkalommal, de valoszinuleg ha nem lesz se keresesi talalati lista, se betoltheto filterek listaja, rajon magatol... ha meg defaultbol listazunk mindent, akkor talan ha kevesbe hangsulyos a fejlec, akkor rajon :)

nezzunk meg egy ilyet is (tettem egy space-t a 2 datum koze):

default kepernyo: http://www.mailpiler.org/screenshots-201201/search11.png
mindig azok a pirulak: http://www.mailpiler.org/screenshots-201201/search12.png
elmentett keresesek betoltese: http://www.mailpiler.org/screenshots-201201/search13.png

Meg azon tunodok, hogy sima user eseten a teljes fenti menut (kereses, osszetett kereses, bealitasok) meg lehetne sporolni, ha a beallitasokat kitennem jobboldalra a 'Nev' es a 'Kijelentekezes' koze, es az egyszeru kereses oldalon lenne egy szoveges link (valahol) az osszetett keresesre, mig az osszetett keresesnel az egyszeru keresesre.

Ha elkeszult az osszetett kereses is, akkor csinalok az egeszbol egy demot, es akkor eloben ki lehet probalni az egeszet a weben. Majd keresek hozza egy vps szolgaltatot :-))

Palgium

feliratkozás

----------
Az Örömtündér minden évben ellátogat a Földre és akit megérint a pálcájával az Boldog lesz! De esetleg az is megtörténhet, hogy kiveri belőled még a sz*rt is... (by radcsong)