ugrás a tartalomhoz

URLs are already dead

Hidvégi Gábor · 2014. Szep. 5. (P), 16.07
Mit jelent a fejlesztőkön kívüli ~1,2 milliárd netező számára az URL?
 ■
1

Semmilyen kutatással

Joó Ádám · 2014. Szep. 5. (P), 16.08
Semmilyen kutatással alátámasztva.
5

Üzlet

Hidvégi Gábor · 2014. Szep. 5. (P), 18.20
Meggyőződésem, hogy az 1,2 milliárd ember legfeljebb a domain-t gépeli be, utána kattintgat, vagy pedig eleve bookmarkot nyit meg. Az első / jel utáni tartalomnak a jelentősége csak elméleti.

Szerintem ez nem más, mint üzlet, méghozzá ebben az esetben a SEO-sok részéről. A google algoritmusa optimista esetben egy kétszáz változóból álló egyenlet alapján adja a találatokat, ezekből egy lehet az url. Nem biztos, hogy az, de valószínű. Az url szorzóját nem ismeri senki, csak a legbelső és legmegbízhatóbb munkatársak, pár ember. Mindenki más csak találgatni tud, és nem tudjuk, hogy van-e különbség az article?id=26 vagy a /szep_cim között, és hogy az utóbbi tényleg többet ér-e.

A másik ilyen a gyorsaság – amíg a válaszidő nem másodperceket tesz ki, az átlagfelhasználó nem fog alternatívákat keresni, hisz a sebesség csak egy faktor, de a másik oldalon a termék lehet, hogy drágább, lassaban szállítják ki, újra be kell regisztrálni, új felhasználói felületet kell megtanulni stb.

A nagy kedvencem a sorban az AJAX, a fejlesztőkön kívül nincs a világon egy ember sem, akit érdekel, hogy újratöltéssel vagy anélkül jön le az oldal egy szelete. Teljesen mindegy nekik, hogy kattintgatás közben el van-e mentve minden, vagy pedig alul egy Mentés gombra kell kattintani, sőt, sokakat megzavar az előbbi viselkedés, mert nem ehhez szoktak hozzá. Az AJAX szerintem a fejlesztők hülyítésének tipikus esete.

Szóval ezek és hasonszőrű társaik szerintem inkább csak arra jók, hogy mi, fejlesztők vegyük meg valakinek a szolgáltatását (keresőoptimalizálás, ilyen-olyan tanácsadás), és jóval kisebb a jelentőségük, mint ahogy azt sokan beállítani szeretnék. És ezzel természetesen nem azt mondom, hogy nem fontosak.
6

Az URL egy név, a jelentősége

Joó Ádám · 2014. Szep. 5. (P), 18.24
Az URL egy név, a jelentősége pontosan akkora, mint bármilyen más névé.
9

99,99%-ban zérus

Hidvégi Gábor · 2014. Szep. 5. (P), 18.32
Sokszor viszont nincs jelentősége a neveknek. Tegyük fel, hogy bemész a postára, és fel szeretnél adni egy levelet, kapsz egy cetlit egy sorszámmal. Ráírhatnák, hogy Kovácsné Gizike fog ott ülni, de ez senkit sem érdekel, mert ő amíg nem ront el valamit, addig nem hordoz információt. Ugyanígy lényegtelen (nem neked, hanem a többieknek), hogy domain.com van a címsorban, vagy pedig domain.com/article?26.
10

Te sorszámozod a fájlokat a

Joó Ádám · 2014. Szep. 5. (P), 18.36
Te sorszámozod a fájlokat a számítógépeden? Képzeld csak el, mekkora élmény lenne használni a parancssort!
11

Egy modernnek nevezett

Hidvégi Gábor · 2014. Szep. 5. (P), 18.45
Egy modernnek nevezett operációs rendszeren a felhasználó a \Documents and Settings vagy a /home egy alkönyvtárába írkál, a létrehozott fájlok száma pedig elenyésző az operációs rendszer és az alkalmazások által felhasználtakhoz képest, egy átlagfelhasználó gépén szerintem száz az egyhez az arány. Ennyi erővel a rendszer- és applikációs fájlok akár lehetnének sorszámozottak vagy állhatnának kínai karakterekből, mivel pártíz kivételével egyikhez sem nyúlunk hozzá.
13

Nem tudom, hogy honnan

Joó Ádám · 2014. Szep. 5. (P), 18.54
Nem tudom, hogy honnan veszed, hogy a rendszerfájlok száma nagyobb, mint a felhasználói fájloké, de igazság szerint azt sem értem, hogy jön ez ide. A rendszerfájlok a fejlesztők számára felhasználói fájlok, azért van nevük, hogy a fejlesztők eligazodjanak köztük. Megint csak nem értem, hogy ez mire érv.
14

Arra próbáltam utalni, hogy a

Hidvégi Gábor · 2014. Szep. 5. (P), 19.05
Arra próbáltam utalni, hogy a neveknek jóval kisebb a jelentősége, mint ahogy hisszük. Másrészt pedig arra, hogy ne magunkból induljunk ki, akik számára a fájlok munkaeszköz; mert egy átlagfelhasználó gépén mi van? Pár pdf, mp3-ak, esetleg néhány videó. Ezeknek a száma elenyésző a gépen lévő, ezen fájlok megtekintését lehetővé tevő programok fájljainak számához képest. Az online szolgáltatások elterjedésével pedig belátható időn belül a felhasználói állományok száma nullára fog csökkenni, lásd Chromebox.
20

Mert hogy ha valaki nem

Joó Ádám · 2014. Szep. 5. (P), 19.19
Mert hogy ha valaki nem fejlesztő, akkor a fájlok már nem is munkaeszköz számára? Az, hogy a saját gépén vagy a felhőben, lényegtelen.
15

a létrehozott fájlok száma

inf · 2014. Szep. 5. (P), 19.06
a létrehozott fájlok száma pedig elenyésző az operációs rendszer és az alkalmazások által felhasználtakhoz képest, egy átlagfelhasználó gépén szerintem száz az egyhez az arány


Na erre kíváncsi vagyok!
16

System | C: | minden

inf · 2014. Szep. 5. (P), 19.09
System | C: | minden telepített szoftver plusz oprendszer
274.874 fájl

Data | D: | minden adatfájl
367.394 fájl
18

Átlagfelhasználó vagy?

Hidvégi Gábor · 2014. Szep. 5. (P), 19.15
Átlagfelhasználó vagy? Van okostelefonod? Azon nézd meg a fájlok arányát!
21

A mobileszköz a limitált

Joó Ádám · 2014. Szep. 5. (P), 19.23
A mobileszköz a limitált interfésze, illetve relatív kicsi tárkapacitása miatt elsősorban megtekintésre és nem létrehozásra/kezelésre/tárolásra alkalmas, így ez sokat nem jelent.

Egy átlagfelhasználó is rengeteg dokumentumot, könyvet, fényképet, filmet tárol.
28

A programozós projektjeim

inf · 2014. Szep. 5. (P), 20.54
A programozós projektjeim ebből olyan 30.000 fájl. A többi kép, könyv, cikkek, jegyzetek, film, zene, stb... Bárki, akinek van egy digitális fényképezője, és használja is néha, simán összehozhat vele több tízezer képet néhány év alatt...
29

Így van. És mi a képek neve?

Hidvégi Gábor · 2014. Szep. 5. (P), 21.52
Így van. És mi a képek neve? IMG_0776.jpg
30

A kép készítésének pontos

Joó Ádám · 2014. Szep. 5. (P), 22.04
A kép készítésének ideje másodperc pontossággal. A mappáé az adott esemény.
33

Ez a fényképezőgépből "jön

Hidvégi Gábor · 2014. Szep. 5. (P), 22.16
Ez a fényképezőgépből "jön ki" így, vagy te nevezed át és te hozod létre az esemény könyvtárát? Szerinted a nagy többség is így szortíroz (a mappába rendezés mondjuk valószínűleg igen)?
35

Azt kell, hogy mondjam, egyet

inf · 2014. Szep. 6. (Szo), 00.16
Azt kell, hogy mondjam, egyet tudok érteni kivételesen. Illetve hierarchikus elrendezés helyett (könyvtárak) szerintem jobb lenne felcímkézni a tartalmakat, és címkék alapján keresni, ahelyett, hogy végigmászni a hierarchiát. Rengeteg programozással kapcsolatos leírásom van itthon, és rémálom a rendszerezésük, mert egyszerűen nem illenek bele egy merev hiearchiába. Valamelyik fájl tisztán több kategóriába tartozik, a parancsikonok létrehozása és másolgatása meg elég kényelmetlen dolog... Ezek után, ha meg akarok találni valamit, akkor kénytelen vagyok végigmászni a könyvtárakat, ahol lehet, aztán talán harmadikra, negyedikre meg is találom. A másik opció a kereső használata, ami nem működik, hacsak nem valaki felsorolja az összes címkét a fájlnevekben. Próbáltam felvinni az infot egy issue trackerbe, hátha az ottani kategóriákkal tudok kezdeni valamit, de az sem működik. Csak pár szintes a hierarchia a kategóriáknál, a címkéknél meg egyáltalán nincsen. És akkor arról ne is beszéljünk, hogy előfordulhat, hogy több főkategóriába megint csak ugyanazok az alkategóriák bekerülhetnek. Szóval a hierarchia nálam teljes mértékben megbukott, és címke gráfra, illetve tartalom címkézésre lenne szükség helyette. Szoftverfejlesztésnél nem hiszem, hogy különösebb nehézséget okozna alkalmazni egy ilyen rendszert, mert ugyanúgy visszamenőleg meg lehet támogatni vele a hierarchiát és a fájl neveket.
40

Ez nagyon érdekes ötlet. Az

Hidvégi Gábor · 2014. Szep. 6. (Szo), 06.49
Ez nagyon érdekes ötlet. Az újabb windowsok/ntfs fájlrendszer nem támogatnak ilyen címkézést?
41

Vista óta igen

complex857 · 2014. Szep. 6. (Szo), 07.39
Windowsban elvileg Vista óta van ilyen (én magam sose használtam): Add tags or other properties to a file

Maga az ötlet persze nem újdonság, anno a BeOS fájlrendszere támogatott úgynevezett "attributes" nevű dolgot minden fájlon ami key-value store-ra emlékeztetett amiben utána lehetett keresni, indexelve volt és volt hozzá query api ami támogatott mindenféle szokásos dolgot mint kissebb/nagyobb és hasonlók. Részletek itt, 5. fejezet környékén..
42

Köszönöm

Hidvégi Gábor · 2014. Szep. 6. (Szo), 08.29
Akkor jól emlékeztem.
43

Én egy darabig hardlinkeket

Joó Ádám · 2014. Szep. 6. (Szo), 11.23
Én egy darabig hardlinkeket használtam arra, hogy több könyvtárból is elérhetőek legyenek a fájlok, ezzel a könyvtárak hierarchikus címkerendszerré váltak. Sajnos azonban egy fájlrendszerek közti másoláskor a kapcsolat elvész, és önálló kópiák keletkeznek, ami több szempontból is használhatatlanná teszi a módszert. Jó volna eljutni végre a content addressable fájlrendszerekhez.
47

Kutatás

Hidvégi Gábor · 2014. Szep. 6. (Szo), 15.04
Te tudsz linkelni olyan kutatás(oka)t, ami azt támasztja alá, hogy a "szép url"-ek a felhasználók számára jobban kezelhetők, hatékonyabbak?
48

A cikk nem a szép URL-ekről

Joó Ádám · 2014. Szep. 6. (Szo), 17.05
A cikk nem a szép URL-ekről szól.
51

Igaz

Hidvégi Gábor · 2014. Szep. 6. (Szo), 17.52
Igaz. Kíváncsi lennék, hogy a teljes url elrejtésének hatásait kutatták-e.
2

Nekem elég csak megnéznem,

inf · 2014. Szep. 5. (P), 17.48
Nekem elég csak megnéznem, ahogy anyám netezik. Beírja a címsorba, hogy origo. Ha nem jön elő, hogy origo.hu, akkor tanácstalan, akkor beírja, hogy google, aztán a keresőbe írja, hogy origo. Szerintem a többség azt se tudja mi az, hogy URL, és akkor még csak nem is IP címről beszéltem... Biztonsági szempontból elég gáz, ha csak arról ismerik fel a bankuk webes felületét, ahogy kinéz, és meg sem nézik, hogy milyen domain-hez tartozik...
7

És kinek a felelőssége ez?

Joó Ádám · 2014. Szep. 5. (P), 18.26
És kinek a felelőssége ez? Kinek nem sikerült huszonöt év alatt kommunikálnia a felhasználók felé, hogy mi az az URL?
17

Passz. :-)

inf · 2014. Szep. 5. (P), 19.11
Passz. :-)
3

Nem lett bevezetve

Poetro · 2014. Szep. 5. (P), 18.08
Annyi ellenséges véleményt kaptak, hogy azóta se lett bevezetve az URL elrejtése, pedig már 3-4 főverzióval odébb járunk.
4

Irreleváns

Hidvégi Gábor · 2014. Szep. 5. (P), 18.18
Ha nem lett bevezetve, akkor valószínűleg a fejlesztők torpedózták meg, hisz egy nem fejlesztő nem olvas böngészőkkel kapcsolatos híreket, tehát ez nem jelzi azt, hogy valóban szükség van a teljes url megjelenítésére.
8

Az URL nem a fejlesztőknek

Joó Ádám · 2014. Szep. 5. (P), 18.30
Az URL nem a fejlesztőknek szól. Az URL része a felhasználói interfésznek. Attól, hogy az emberek egy jelentős része nem érti a fájlhierarchiát, és a Word Fájl menüjéből nyitja meg a dokumentumait, még nem jelenti azt, hogy innentől vissza kell térni a lapos fájlrendszerekhez. Esetleg azt az energiát, amit ez efféle kontraproduktív innovációra fordítanak, lehetne egy olyan felhasználói felületre, ami egyértelművé teszi az URL jelentőségét.
12

Az emberek azért nem

Joó Ádám · 2014. Szep. 5. (P), 18.50
Az emberek azért nem használják az URL sávot, mert negyed évszázada nem fejlődött semmit: egy szövegdoboz, amihez hozzányúlni a hozzáértőnek fárasztó, a laikusnak ijesztő.

Hogyan kellene kinézzen? Strukturált felületnek, egyenként – kiegészítéssel! – hozzáadható és szerkeszthető, törölhető szegmensekkel, lehetőséggel a fában történő navigációra, információval az egyes szintekről, a query string módosításához külön, táblázatos komponenssel.
19

Nem rossz ötlet, bár ezek a

Hidvégi Gábor · 2014. Szep. 5. (P), 19.16
Nem rossz ötlet, bár ezek a komponensek, szétszórva bár, de ott vannak a weboldal felhasználói felületén (sitemap, linkek, gombok a rendezéshez stb.).
22

És úgy gondolod, hogy egy

Joó Ádám · 2014. Szep. 5. (P), 19.27
És úgy gondolod, hogy egy szabványos interfész nem ad hozzá értéket? Arról nem is beszélve, hogy Berners-Lee így találta ki, az URL-ek ilyenek maradnak, akkor már akár kényelmessé is lehetne tenni a használatukat.
23

Nem azt mondom, hogy rossz

Hidvégi Gábor · 2014. Szep. 5. (P), 19.30
Nem azt mondom, hogy rossz ötlet - ki kell próbálni. Kell hozzá a weboldal részéről egy API, valamint egy böngésző, ami támogatja. Ez utóbbit akár egy ActiveX beillesztésével meg lehet oldani.
24

Nem kell hozzá API, a

Joó Ádám · 2014. Szep. 5. (P), 19.38
Nem kell hozzá API, a jelenlegi URL és a history alapján már működik. Természetesen, ha valamilyen szabványos formában leírhatóak az URL-ek, az még jobb, de kezdetnek csak kliensoldalon szükséges fejlesztés.
25

Nem intuitív

Hidvégi Gábor · 2014. Szep. 5. (P), 19.55
Ez így sok pluszt nem adna, főleg a modern url-eknél, amelyek ilyen formában néznek ki:
http://thepiratebay.se/search/alien%201979/0/99/200
Itt az utolsó előtti szám vezérli a rendezést, azaz, ha a következőképp néz ki:
http://thepiratebay.se/search/alien%201979/0/5/200
akkor méret szerint sorrendez.

Vagy például az edigitalnál:
http://www.edigital.hu/Szamitastechnika/Monitor-c1067.html
ár szerint rendezve
Túl hosszú lenne, húzd ide az egeret
Valami alapján ki kell találni, hogy melyik paraméter mit jelent, tehát API nélkül nem sokat ér az egész, valamint egységes paraméterkezelés is szükséges.
26

A Pirate Bay egyértelműen

Joó Ádám · 2014. Szep. 5. (P), 20.18
A Pirate Bay egyértelműen rosszul használja az URL-eket, azoknak a paramétereknek a query stringben kellene lenniük. A nevek alapján azért kitalálható, hogy mi mit jelent. Nyilván, ha le lehet írni a címeket valamilyen feldolgozható formában, az megsokszorozza a használhatóságát, de az szabványosítási munkát és fejlesztői közreműködést igényel, míg az ismert URL-ek strukturált formában való megjelenítéséhez elég a böngésző UI-t bővíteni.
27

Szabvány

Hidvégi Gábor · 2014. Szep. 5. (P), 20.48
Korábban már gondolkoztam az url-eken (más kontextusban), de arra jöttem rá, hogy a paraméterek neveivel még sokra nem megyünk, az értékeket egyrészt érteni kell, másrészt pedig tudni kell, hogy miből lehet választani. Az edigital például az ár szerinti növekvő sorrendezést az orderby=price&order=0 paraméterekkel oldotta meg, míg választhatták volna a következőt is: orderby=price_asc. Így igazából csak az url előzmények állnak a rendelkezésünkre, amivel kezdeni lehet bármit is, ezt meg már kezelik a böngészők, mert bal oldalon kiírják az url-t, jobb oldalt meg az oldal címét.

Nem tudom, hogy ennél hatékonyabb lenne-e az általad vázolt ötlet (anélkül, hogy bárkinek is túl sok energiát kellene belefektetnie jobban olvasható url-ekbe). Szabványosítás nélkül nem tudom, mit lehet a jelenlegi helyzetből kihozni. Ha meg nem értjük sem a paramétert, sem pedig az értékét, akkor nem mindegy, hogy néz ki? De, jelenleg szerintem igen.

Az más kérdés, hogy mindenképp célszerű lenne szabványosítani az url-ekben lévő paramétereket, mert ekkor könnyebben lehetne keresni.
32

Az tény, hogy rossz választás

Joó Ádám · 2014. Szep. 5. (P), 22.13
Az tény, hogy rossz választás volt gépi oldalról átlátszatlan sztringként definiálni az URL-t, de a jelenleg is létező használati mintán (és itt lényegtelen, hogy mennyi felhasználó használja) sokat segítene egy strukturált felület. Így is át fogom írni a paramétereket, és feljebb fogok lépni szinteket, csak sokkal kényelmetlenebb a folyamat. A felajánlott előzmények pedig jelenleg például a Chrome-ban közel használhatatlanok számomra, mert nagyszámú, teljes, adott esetben komplex URL-ből ajánl fel valamilyen önkényes algoritmus által néhányat, így esélytelen, hogy egy cím szerkesztésekor ugyanazt a segítséget adja, mintha szerkezetében értelmezné.
31

A Pirate Bay egyértelműen

Hidvégi Gábor · 2014. Szep. 5. (P), 22.13
A Pirate Bay egyértelműen rosszul használja az URL-eket, azoknak a paramétereknek a query stringben kellene lenniük.
Ezt így érzed. Nézd meg a wikipédia "szemantikus" url című cikkében felhozott egyik példát:
nem szemantikus: http://example.com/products?category=2&pid=25
"szemantikus": http://example.com/products/2/25

Ez mitől jelent többet (mitől szemantikusabb), mint a fentebbi? Ha érthetővé szeretnénk tenni egy címet, akkor kulcs=érték formában kéne szerepelnie a paramétereknek, különben nem érnek semmit. Ez viszont csak azt bizonyítja, amit az 5-ös hozzászólásban leírtam.
34

A szegmens és query string

Joó Ádám · 2014. Szep. 5. (P), 22.20
A szegmens és query string közötti választáshoz nincs egyértelmű szabály, de a kereső beállítások tipikusan olyanok, amik az utóbbiba valóak, már csak azért is, mert a kedvükért lett feltalálva.

A saját ökölszabályom szerint paraméterbe az való, amit elhagyva ugyanazt az oldalt kapom, valamilyen más beállítással. Rendezés, szűrés, választott formátum, egyes szekciók megjelenítése/elrejtése stb.
37

A saját szabályok helyett

inf · 2014. Szep. 6. (Szo), 00.34
A saját szabályok helyett inkább olvasd el a specifikációt.
The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.
38

Hol látod, hogy ellentmondok

Joó Ádám · 2014. Szep. 6. (Szo), 01.55
Hol látod, hogy ellentmondok a specifikációnak?
44

A szegmens és query string

inf · 2014. Szep. 6. (Szo), 12.31
A szegmens és query string közötti választáshoz nincs egyértelmű szabály
49

Nem látom a szabályt az

Joó Ádám · 2014. Szep. 6. (Szo), 17.07
Nem látom a szabályt az idézett szövegben :(
52

Az a szabály, hogy nincs

inf · 2014. Szep. 6. (Szo), 18.21
Az a szabály, hogy nincs szabály. A hierarchikus részt a path-be érdemes tenni, a nem hierarchikus részt meg a query-be. Ezen kívül két hasonló IRI bár nem logikus, de simán tartozhat két tetszőleges erőforráshoz. Nincs ilyen megkötés, legalábbis én még nem találkoztam vele egyik specifikációban sem.

A meaningful IRInek csak routing vagy link építés szempontjából van jelentősége, illetve weboldalaknál SEO szempontjából ki tudja mekkora. Szóval az esetek döntő többségében csak a fejlesztők dolgoznak vele. A felhasználónak édesmindegy, hogy mi van az IRI-ben, megosztáskor copy-paste-eli, egyébként meg csak a domain érdekli. A böngészők sem jelenítik meg, linkeknél külön címet kell adni neki, az ablakoknál, lapoknál meg title-t jelenítik meg helyette, szóval egyedül a címsorban kap helyet. Nekem legalábbis ez a tapasztalatom. Nem véletlen, hogy a legtöbb felhasználó azt sem tudja, hogy micsoda. Mindenki kattintgatással, és űrlap küldéssel navigál, és ez így jó, mert ez volt a hypermedia eredeti célja, hogy linkeket kövessünk, ne pedig kézzel gépeljük be az IRIket. Bevált.
54

Akkor nem értem, mi bajod

Joó Ádám · 2014. Szep. 6. (Szo), 19.24
Akkor nem értem, mi bajod vele, ha én konzisztensen próbálok választani a kettő közül…?

A felhasználónak édesmindegy, hogy mi van az IRI-ben, megosztáskor copy-paste-eli, egyébként meg csak a domain érdekli.


1) Továbbra is várom az ezt az állítást alátámasztó kutatást.
2) Kezd kibaszottul felháborítani, hogy engem senki nem vesz felhasználószámba. Én olvasom és átírom az URL, s amikor a te alkalmazásodat használom, akkor annak a felhasználója vagyok.

A böngészők sem jelenítik meg, linkeknél külön címet kell adni neki, az ablakoknál, lapoknál meg title-t jelenítik meg helyette


A böngészők megjelenítik, a linkeknek az átlagfelhasználó nem ad címet, a title médiafüggő és nem mond róla semmit, hogy hol tartózkodom.

ez így jó, mert ez volt a hypermedia eredeti célja, hogy linkeket kövessünk, ne pedig kézzel gépeljük be az IRIket


Nem tudom, hogy ez volt-e a hypertext eredeti célja, még mielőtt Fielding utólag aláépítette a doktori disszertációját, de az biztos, hogy a web célja és sikerének egyedüli oka a címezhetőség, szemben a kattintgatással, ami minden grafikus platform sajátja.
55

Déjà vu

complex857 · 2014. Szep. 6. (Szo), 21.36
1) Továbbra is várom az ezt az állítást alátámasztó kutatást.

Azt kockáztatva, hogy magamat ismétlem (mert meg mernék rá esküdni, hogy ezt a kört már egyszer lefutottuk valahol a weblaboron és a böngészőm visitednek jelöli a lenti linket), de az egyetlen kutatás amiről tudok és kapcsolódik ide az pont azt mondja ki, hogy URL-ek elég fontos szerepet döntenek el a kereső találatok közötti választásban: An eye-tracking study of information usage in Web search (2007, Microsoft).
We were particularly surprised to see the overwhelming endorsement of the URL because this is often characterized as a “power-user” feature that is used by only a small percentage of users.

A kutatás mérései alapján kvázi az idő 24%-ban az URL-t nézik a látogatók az egyes bejegyzésekben (cím és snippet teszi ki az idő többi részét), de a konklúzió elég összetett (ami hasznosnak tűnik bizonyos fajta sitehoz az káros lehet más fajtánál egy találati oldalon), érdemes elolvasni.

Ez persze nem alátámasztja az "felhasználót nem érdekli az URL" hipotézist, hanem inkább cáfolja, legalábbis kereső találat oldalakon, de annál rosszabb a tényeknek.
56

Nem értem, te akkor most

Joó Ádám · 2014. Szep. 6. (Szo), 21.39
Nem értem, te akkor most milyen következtetést vonsz le.
57

Punks not dead

complex857 · 2014. Szep. 6. (Szo), 21.44
Nos nekem úgy tűnik, hogy URL-ek élnek és virulnak.
58

Ez egy speciális eset,

Hidvégi Gábor · 2014. Szep. 6. (Szo), 21.59
Ez egy speciális eset, keresésnél és külső oldalra vivő megjelölt linkeknél hordoz információt az URL (én pl. soha nem kattintok t.co-s vagy bit.ly-s címre), de amikor egy konkrét site-on vagy, akkor biztos vagyok benne, hogy nem nézed, mit nyitsz meg, vagy legalábbis jóval kevesebb figyelmet szánsz rá, mint 24%.
59

Lehet, hogy az vizsgált eset

complex857 · 2014. Szep. 6. (Szo), 22.22
Lehet, hogy az vizsgált eset speciális, de a felmérés alapján nekem úgy tűnik, hogy a felhasználók:
  • Van valami elképzelésük arról, mi is lehet az URL
  • Tudják, hogy alapvetően navigáció támogatására használható
Ezeket akkor se felejtik el ha épp nem egy kereső oldalt néznek, így az eredeti cikk konklúziója miszerint:
Most end-users don’t understand URLs any more than they understand phone numbers.
szerintem téves, legalábbis egy darab felmérés szerint még 2007-ből.
A cikk írója később commentben megerősíti, hogy írása csak saját tapasztalatain alapszik (külön mókásnak találom, hogy mivel nem volt permalink az oldalon Firebug + urlbar-ba pötyögéssel állítottam elő a linket :P)

Az, hogy a google megpróbálja az URL-ket fogyaszthatóbb formában megjeleníteni (ha már ennek apropóján született a cikk) lehet csak arra utal, hogy szerintük most nem elég lényegretörőek vagy olvashatóak - és lenne az ami lehet sokak "hibája" és ami ellen fejlesztő megpróbálhat tenni valamit - nem arra, hogy úgy általában értéktelenek felhasználóknak, de ez már csak találgatás a részemről.
63

Információérték

Hidvégi Gábor · 2014. Szep. 7. (V), 12.34
Az URL értékes, de csak addig, amíg hordoz információt. Keresésnél ellenőrizni kell, hogy mit nyitsz meg, és egy URL-ből sokmindent ki lehet deríteni, például a domain-ből vagy aldomain-ből tudom, hogy olyan bloggeré, akivel ellenkezik a véleményem, ezért rá sem kattintok. Az is nyilvánvaló, hogy az átlagfelhasználó nem hülye, és hasonló következtetéseket tud levonni, mint a szakemberek, mielőtt bármit cselekedne.

De miután megnyitok egy oldalt, a "baj már megtörtént", és nem leszek attól okosabb, ha a böngésző tetején ott van a teljes cím. Mivel eszközök nélkül nehézkes a használata (eleve minden browserben az első kattintásra kijelöli az egészet, tehát minimum kétszer kell ráböknöm, ha módosítani szeretném, a betűk pedig kicsik, azaz idővel egyre nehezebb benne kijelölni), nem véletlen, hogy funkcióját összevonták a keresőmezőével, sorvad. Így viszont nem több, mint egy egyre kevésbé használható elem, ami csak a helyet foglalja.

Innentől kezdve el lehet gondolkodni, hogy egy URL összeállítására, kozmetikájára mennyi erőforrást érdemes áldozni. Szerintem minimálisat, a kezeléséhez szükséges eszközök hiánya miatt a lapos struktúra (domain.hu/akarmi.html) pont ugyanolyan megfelelő, mintha megpróbálnám hierarchiába szervezni.

Ha mégis az utóbbi mellett döntök, akkor mind szerver-, mind pedig kliensoldalon kezelni kell, azaz például az origo.hu/gazdasag/akarmi.html címből következően az origo.hu/gazdasag/-nak is élőnek kell lenni, és erre linket is el kell helyezni. Rossz példa erre a blog.hu, ahol bár "szép" url-ek vannak, és élnek is, azaz visszatörléssel lehet benne navigálni, például http://szemantikus.blog.hu/2011/02/28/szemantika_a_html_ben, de a jobb oldali archívumban a februári összes bejegyjés már a http://szemantikus.blog.hu/2011/2 címre mutat (egy nulla eltűnt, azaz nem konzekvens), míg ha 2011 összes írását szeretném megnézni, erre nem lehet találni hivatkozást.

Az URL kiírásának két helyen van értelme: a keresőben, valamint az állapotsorban, amikor felé viszem az egeret.

Ráadásul a tipikus "szép" URL-ek, amelyek arra a sablonra épülnek, amit fentebb a blog.hu kapcsán illesztettem be, csak az emberek számára hordoznak információt, mert ránézünk, és vagyunk olyan intelligensek, hogy tudjuk, a bejegyzés címe előtt egy dátumot látunk. Ezt egy gép jóval kisebb eséllyel ismeri fel, három egymást követő szám lehet dátum, de akár egy akta száma is. Emiatt, bár az angol szakirodalom szemantikusnak nevezi, valójában jóval kevesebb információt hordoz gépek számára, mint a következő: szemantikus.blog.hu?bejegyzes=szemantika_a_html_ben&datum=2011-02-28. Mivel egy kereső sosem tudhatja, hogy a perjelekkel elválasztott hierarchia valóban létezik, magától nem fogja kitalálni, hogy az akarmi.blog.hu/2014 url létezik-e, csak akkor, ha van rá a HTML-ben link.

Tehát szerintem a querystringes (vagy azzal ekvivalens) megoldás mind a gépek, mind pedig a humán olvasók számára többletinformációt hordoz a jelenleg elterjedt "clean" URL sémákhoz képest. Márpedig nekünk, fejlesztőknek a keresőket is ugyanúgy ki kell szolgálnunk, mint a látogatókat, mivel az interneten található oldalak egyre növekvő számát csak ezek tudják feltérképezni, számunkra ez lehetetlen feladat.
66

eleve minden browserben az

Joó Ádám · 2014. Szep. 7. (V), 13.09
eleve minden browserben az első kattintásra kijelöli az egészet


Rohadt idegesítő.
67

works4me

complex857 · 2014. Szep. 7. (V), 13.56
Nálam linuxos firefox-ban nem csinálja: demo (-:
68

Lehet, hogy vissza kellene

Joó Ádám · 2014. Szep. 7. (V), 14.02
Lehet, hogy vissza kellene térnem a Firefoxhoz. Majd egy évtized után egy-két éve tértem át a Chrome-ra, amikor az FF teljesítménye a nevetséges szintet elérte…
72

Windowson is lehet

Endyl · 2014. Szep. 8. (H), 10.08
Windowsos firefoxban is be lehet állítani. about:config-ban browser.urlbar.clickSelectsAll-t false-ra állítani és megoldódott a probléma.
Mondjuk én azt szeretem, ha kijelöli az egészet, de ez a pap és papné esete.
75

Sok felhasználónak fogalma sincs az ilyenekről.

Gixx · 2014. Szep. 9. (K), 17.48
What is a Browser?

Nem tudom, mennyire megrendezett, de szerintem nem az, és jól tükrözi az átlag felhasználót. Mert az átlag felhasználót egyáltalán miért érdekelné az URL? És miért akarna különbséget tenni a böngésző és a kereső motor között?

Újságot sem úgy vesznek, hogy elmennek a 1146 Budapest, Thököly út 127. szám alá (URL), és ott kérnek egy aktuális számot, hanem elmennek az újságárushoz (Google) és kérnek egy Népszavát.
76

+1, ismerek én is olyat,

inf · 2014. Szep. 9. (K), 19.58
+1, ismerek én is olyat, akinek az internet az e betű, és lövése sincs arról, hogy mi az, hogy böngésző...

Ettől függetlenül nincs elég statisztikai adatunk, hogy kijelentsük, hogy ez az átlag, de szerintem is közelít hozzá.
62

+1, szerintem is speciális

inf · 2014. Szep. 7. (V), 06.43
+1, szerintem is speciális eset, és csak az ismerős domain neveket keresték,de azért kíváncsi vagyok, hátha van valami extrém magyarázat. ;-)
64

A doksi alapján nem kifejtős

complex857 · 2014. Szep. 7. (V), 12.34
Edit: Mellé nyomtam, valójában #60-ra akartam válaszolni.

A doksi alapján nem kifejtős kérdések voltak, hanem ilyen 1-től 7-ig pontozható "jellemző/nem jellemző rám" így ez sajnos nem derül ki ebből (magukat a kérdéseket nem látom, hogy csatolták volna).
60

Hmm ez érdekes. És

inf · 2014. Szep. 7. (V), 06.21
Hmm ez érdekes. És megkérdezték őket, hogy miért nézik az URL-t?
78

Nem releváns

Hidvégi Gábor · 2014. Szep. 10. (Sze), 09.23
Vettem a fáradságot, és elolvastam a tanulmányt. Sajnos messzemenő következtetéseket nem lehet belőle levonni az aktuális témában, ugyanis az URL-ek minden találat mellett látszottak, és ezt a szerzők is jelzik a 11. oldal tetején:
That is, as more information is included in the results, users may unconsciously down-weight the relevance of URLs for their decisions. When multiple results have rich snippets, it would be more difficult to decide which result is the target for navigational tasks, but this wouldn’t be an issue for informational tasks, where the goal is any Web site likely to have the answer. This idea suggests that users may not consciously realize the benefit they receive from URLs and do not strategically devote attention to different parts of results depending on their task, but rather simply use what they are given.
A következő bekezdésben írják, hogy külön kísérlettel kéne mérni az URL-ek jelentőségét, valamint azt, hogy hatásosabb-e, ha az URL helyett a tartalomból illesztenek be egy újabb sort.
61

Akkor nem értem, mi bajod

inf · 2014. Szep. 7. (V), 06.40
Akkor nem értem, mi bajod vele, ha én konzisztensen próbálok választani a kettő közül…?


Semmi, tedd azt. Csak arra próbáltam felhívni a figyelmedet, hogy létezik olyan, hogy URI specifikáció, amiben világosan le vannak írva, hogy mik a megkötések ezzel kapcsolatban. Tehát létezik szabály a dologra.

A böngészők megjelenítik, a linkeknek az átlagfelhasználó nem ad címet, a title médiafüggő és nem mond róla semmit, hogy hol tartózkodom.

Pontatlanul fogalmaztam, az innerHTML-t értettem cím alatt egy-egy anchor-on belül.

Én olvasom és átírom az URL

Milyen helyzetben teszed ezt? Nálam leggyakrabban akkor, ha google-ben az ismerős, illetve megbízhatónak ítélt oldalak tartalmait akarom csak megnézni.

mielőtt Fielding utólag aláépítette a doktori disszertációját, de az biztos, hogy a web célja és sikerének egyedüli oka a címezhetőség

Hát ez elég erős állítás, hogy ez az egyedüli oka. A címezhetőség fontos, de a linkek ugyanúgy fontosak. Linkek nélkül gyakorlatilag nem létezne a böngésző, mint olyan, hanem csak célalkalmazásokra lehetne klienseket írni. Fielding nem épített át semmit a disszertációjában, a resource identifier-ek ugyanúgy szerepelnek benne, mint eddig.
65

Csak arra próbáltam felhívni

Joó Ádám · 2014. Szep. 7. (V), 13.03
Csak arra próbáltam felhívni a figyelmedet, hogy létezik olyan, hogy URI specifikáció, amiben világosan le vannak írva, hogy mik a megkötések ezzel kapcsolatban. Tehát létezik szabály a dologra.


Hidd el, olvasgattam eleget RFC-t :) És az előbb tisztáztuk, hogy nem létezik rá szabály. Tényleg nem értem, hogy mi akarsz ezzel.

Pontatlanul fogalmaztam, az innerHTML-t értettem cím alatt egy-egy anchor-on belül.


Az az, amit az átlagfelhasználók nem szoktak megadni (általában nincs is rá lehetőségük, lásd például Facebook).

Milyen helyzetben teszed ezt? Nálam leggyakrabban akkor, ha google-ben az ismerős, illetve megbízhatónak ítélt oldalak tartalmait akarom csak megnézni.


Folyamatosan. Mielőtt egy hivatkozásra kattintok, meg szoktam nézni, hova vezet (ugyanitt kiborítónak tartom, hogy divat lett kitakarni a közepét, hogy az állapotsort is megspórolják), többek közt azt is, hogy milyen formátumra, egyáltalán, valódi link-e, és meg tudom-e nyitni új lapon; ha egy CDN-en látok egy bélyegképet, akkor átírom, hogy megnézhessem a nagyot; ha kapok egy deep linket, és érdekel, honnan van, akkor feljebb lépek az URL-szerkesztve; ha megosztok egy címet, akkor a felesleges paramétereket törlöm belőle…

Hát ez elég erős állítás, hogy ez az egyedüli oka. A címezhetőség fontos, de a linkek ugyanúgy fontosak. Linkek nélkül gyakorlatilag nem létezne a böngésző, mint olyan, hanem csak célalkalmazásokra lehetne klienseket írni.


Ugyanúgy működne a web, ha HTML helyett txt fájlokat használnánk, csak kényelmetlenebb volna, hogy át kell másolni a címsorba a hivatkozásokat, nem elég kattintani.

Fielding nem épített át semmit a disszertációjában


Arra céloztam, hogy a hypertext sokkal régebb óta létezik, mint a web, a web pedig régebb óta, mint a REST fogalma, így akármilyen fontos jelentőséget is tulajdonít utólag Fielding – akinek tudom, hogy a REST kapcsán a nézeteit ismered – a címektől független linkeknek, az sokat nem mond ezek valódi szerepéről a web sikerében.
69

Ugyanúgy működne a web, ha

inf · 2014. Szep. 7. (V), 16.06
Ugyanúgy működne a web, ha HTML helyett txt fájlokat használnánk, csak kényelmetlenebb volna, hogy át kell másolni a címsorba a hivatkozásokat, nem elég kattintani.


Kíváncsian várom, hogy mondjuk egy űrlap küldést hogy oldanál meg így...
70

Lehetne éppenséggel egy

Joó Ádám · 2014. Szep. 7. (V), 16.47
Lehetne éppenséggel egy generalizált felület űrlapok kitöltésére a böngészőben, amit a leírásnak megfelelően elküldesz adott címre. De a linkek vonatkozásában beszélgettünk, ahhoz az űrlapoknak nincs köze.
71

Nagyjából ugyanaz a funkciója

inf · 2014. Szep. 8. (H), 02.05
Nagyjából ugyanaz a funkciója az űrlapoknak is, HTTP kéréseket generál mindkettőből a böngésző, és ugyanúgy tartalmaznak URL komponenst.

Elég érdekes világ lenne mindenesetre, ha kézzel kéne bepötyögni az URL-t, illetve az űrlapoknál az input mezők neveit és értékeit, maradjunk ennyiben... :D
73

Szerintem volna egy steampunk

Joó Ádám · 2014. Szep. 8. (H), 15.41
Szerintem volna egy steampunk hangulata :)

Az egésszel csak azt akartam alátámasztani, hogy ami megkülönbözteti a webet az összes más grafikus alkalmazásplatformtól (ami mind alkalmas a kattintgatós navigálásra és űrlapkitöltésre) az a címezhetőség, ez az, ami miatt a web és nem más platform a legsikeresebb.
74

Juhé

Gixx · 2014. Szep. 9. (K), 17.26
A saját ökölszabályom szerint paraméterbe az való, amit elhagyva ugyanazt az oldalt kapom, valamilyen más beállítással. Rendezés, szűrés, választott formátum, egyes szekciók megjelenítése/elrejtése stb.


Végre nem vagyok egyedül :D
36

Simán lehetne:

inf · 2014. Szep. 6. (Szo), 00.32
Simán lehetne: http://example.com/products/category:2/pid:25 tadamm :D
39

Szerintem az részletkérdés,

Hidvégi Gábor · 2014. Szep. 6. (Szo), 06.45
Szerintem az részletkérdés, hogy milyen karaktereket használunk elválasztásra.
45

A specifikáció szerint nem, a

inf · 2014. Szep. 6. (Szo), 12.35
A specifikáció szerint nem, a path-ba kell menni a hierarchikus résznek, a query-be meg a nem hierarchikusnak. Ennyi. Jelen esetben hierarchikusnak tűnik, amit le akarunk írni, szóval a path-be való. Természetesen el lehet térni a specifikációtól, ha ahhoz van kedved, de akkor ne állítsd azt, hogy ez az ajánlás, és mindenkinek így kellene, hogy a query-be pakol mindent.
46

Hierarchia

Hidvégi Gábor · 2014. Szep. 6. (Szo), 14.53
Nem tudom, hogy a hierarchia megjelenítésének van-e értelme az URL-ben, amíg nincs hozzá eszköz, amivel kezelni lehet (lásd Ádám ötlete). A felhasználói felületen erre ott van a navigációs sáv (kenyérmorzsa), az egy elfogadott és jól használható eszköz.
50

Az, hogy mit tekintesz

Joó Ádám · 2014. Szep. 6. (Szo), 17.09
Az, hogy mit tekintesz hierarchikusnak (és mi a hierarchia kialakításának szempontja), teljesen szubjektív.
53

Persze, hogy az. Ezért látni

inf · 2014. Szep. 6. (Szo), 18.26
Persze, hogy az. Ezért látni ilyen IRIket pl lapozásnál, hogy

/users/name:Anna/count:25/offset:50
/users?name="Anna"&count=25&offset=50
/users?name="Anna"

Mindegyik teljesen valid. Az egyik szerint a map reduce hierarchikus, és a reukált felhasználó lista az eredeti sub-resource-a, a másik meg úgy értelmezi a map reduce-t ebben az esetben, hogy nem hierarchikus, és a redukált felhasználó lista az eredeti resource egy eltérő reprezentációja, semmi több. Nyilván ez utóbbi kihasználja, hogy egy resource-hoz több eltérő IRI is tartozhat. A harmadik ennél is tovább megy, és a pagination-t range header-ekre bízza.
77

Csak hogy valami építő

inf · 2014. Szep. 10. (Sze), 04.34
Csak hogy valami építő jellegűt is hozzászóljak, teljesen mindegy, hogy a felhasználók használják e vagy sem. Szerintem át lehetne nevezni a topic-ot the address bar is dead-re esetleg. Maga az URL a web alapja, nélküle nem menne a webes erőforrások azonosítása, hyperlinkek készítése, szóval teljesen kizárt, hogy eltűnjön. Alapvetően a címadás is a hozzá nem értést tükrözi...
79

Zakas nem hülye, szoktam

bamegakapa · 2014. Szep. 10. (Sze), 10.51
Zakas nem hülye, szoktam olvasni tőle, de itt a címadás engem elriasztott. Az "ABC is dead" fajta címek számomra jelzik, hogy ez valószínűleg nem nekem szól. Értem én persze, hogy ez kell a tömegeknek, mert erre jönnek, a szélsőségeket keresik, de azért örülnék, ha nem ez lenne a szint.

Én az elején úgy vettem le, hogy Gábor egyik megszokott témáját, a "szép url"-ek feleslegességét igyekszik a cikkel alátámasztani, szerintem a cikk nem erről szól. Attól hogy az emberek nem nézik mondjuk a változóneveimet, csak jobb beszédes neveket használni. Ugyanígy az URL is szerencsésebb, ha olvasható, plusz információt hordoz, általánosan elfogadott elvekre épül.

Ami a cikket illeti, én nem örülök az URL eltüntetésének, nekem információt hordoz (jó esetben). Ha opcionális, az belefér, csak tudjam visszakapcsolni. Ha a tömegek szokásaira alapozunk, akkor a Word funkcióinak 99%-át ki lehetne venni, úgyis szpésszel zárnak középre és enterrel csinálnak térközt.
80

Én az elején úgy vettem le,

Hidvégi Gábor · 2014. Szep. 10. (Sze), 12.04
Én az elején úgy vettem le, hogy Gábor egyik megszokott témáját, a "szép url"-ek feleslegességét igyekszik a cikkel alátámasztani
Akkor rosszul vetted le. Az írás kulcsmondatai számomra ezek:
We geeks tend to forget that we don’t own the web. The web is not just for us.
És ebből következik az, amit az ötös hozzászólásban írtam (és végeredményül a "szép url"-ek feleslegessége). Pár mondaton belül nálad is kiderül, hogy te is úgy gondolkodsz, mint a többiek (és ezzel most nem személyeskedni szeretnék, ez van, ilyenek vagyunk mi, emberek):
én nem örülök az URL eltüntetésének, nekem információt hordoz
Zakas pont azt magyarázza, hogy mi csak egy elhanyagolható kisebbségét képezzük a web használóinak (szerintem még az IE6-ot is többen nyüstölik), ezért nyugodtan fel lehet tenni a kérdést: kit érdekel, hogy neked mi a jó? És ezzel nem azt mondom, hogy ezzel nem kell foglalkozni, hanem azt, hogy alapból a böngésző működjön úgy, ahogy a többségnek jó, de lehessen úgy beállítani, hogy ha te látni szeretnéd a teljes URL-t, akkor ez legyen egyszerűen megoldható.

Az egyetemen terméktervezőnek tanultam, és ergonómiából az első órán elmondták, hogy a mérnökök által legtöbbször elkövetett hiba az, hogy a termékeket igazából maguknak készítik, és nem kérdezik meg a felhasználókat, hogy nekik mire van szükségük. Mi, webes programozók pontosan ugyanígy viselkedünk, egy rózsaszín burokban alkotunk, de arról nem sokunknak van fogalma, hogy az általunk készített oldalak látogatói mit szeretnének.

Érdemes elolvasni a kontroverziális írásaimra kapott kommenteket. Amikor feltettem a kérdést, hogy mire jók a HTML5-ben bevezetett új elemek, tipikusan olyan válaszokat írtak a kollegák, hogy "jobban olvashatóvá, strukturálhatóvá teszi a kódot", és erre feltettem a kérdést, hogy "kit érdekel, hogy neked mennyire olvasható?", hisz nem neked készül az oldal, hanem a látogatóknak, ettől függetlenül arra még senki sem tett komolyabb erőfeszítést a HTML-lel kapcsolatban, hogy az interneten található mérhetetlenül sok információban könnyebben lehessen keresni a látogatóknak. Ugyanez volt, amikor felvetettem az animációk kikapcsolásának lehetőségét, vagy azt, hogy vigyázni kell az AJAX-szal.

Nagyon jó a Gixx által belinkelt videó, abban elmondják, hogy az emberek 8%-a tudta megmondani, mi az a böngésző. Ők a felhasználók, a többség.
81

Persze, hogy így gondolkozom.

bamegakapa · 2014. Szep. 10. (Sze), 12.33
Persze, hogy így gondolkozom. Valaki már írta, nagyon egyet is értek, hogy én a böngészőnek FELHASZNÁLÓja vagyok. Az a felhasználó, aki érti is, amit használ.

Egyetértek azzal, hogy kisebbség vagyunk, és ezt el is fogadom. Azért a fejlesztőkön túl vannak még bőven, akik tudják, mi az az URL és társai, nem csak zombiként nyomkodják a gombokat. Velük együtt azért már vagyunk annyian (pár százalék is már fontos mennyiség), hogy érdemes legyen minket figyelembe venni. Ráadásul ezek az emberek hajlandóak tanulni, szeretnek felfedezni. Tőlük is elvesszük a lehetőséget, hogy esetleg megértsék a működést (azért valljuk be, az alapok nem atomfizika). Felmerülhessen legalább a kérdés, hogy az ott mi és mire jó.

Értem az érveidet, részben egyet is értek, de nem csak a teljesen hülyéknek kéne tervezni az "internet"-et, elvéve a tanulás, fejlődés lehetőségét. A középút lenne itt is az ideális.

A HTML5-öt meg a többit ne keverjük ide, az teljesen más téma :). A fejlesztő dolgát sem hülyeség megkönnyíteni, mindenki által ismert okokból, de ezt ott elegen kifejtették, igen jól.
82

Ezt én is így látom. Ha

kuka · 2014. Szep. 10. (Sze), 12.41
Ezt én is így látom. Ha vannak igényes és igénytelen felhasználók, miért az igénytelenek világnézete kell legyen az irányadó? Csak mert ők vannak többségben még nem jelenti, hogy ők képviselik a fejlődést.
83

Vigyük tovább a fonalat

Hidvégi Gábor · 2014. Szep. 10. (Sze), 13.26
Amikor Firefoxot használok, szeretem, ha nyitva van a Firebug, mert rengeteg hasznos információt nyújt, például látom, hogy milyen kéréseket és hova küld el a háttérben, így, ha szükséges, rögtön frissíteni tudom a reklámblokkoló szűrőjét. Úgy gondolom, hogy mindenki igénytelen, aki nem így böngészik, kötelezővé tenném a használatát.

Ennek a témának a címe http://weblabor.hu/blogmarkok/129314. Amikor ezt a választ pötyögöm, a címsorban azt látom, hogy http://weblabor.hu/blogmarkok/129314/hozzaszolas/109706. Tudom azt, hogy ha másik hozzászólásra szeretnék válaszolni, akkor az utolsó számot kell átírnom. Ehhez nem kell mást tennem, mint a permalinkben megkeresni a másik hozzászólás azonosítóját, kijelölni, kimásolni a vágólapra és beilleszteni. Jó lenne, ha a címsort jobban kiemelnék, vonzaná a tekintetet, így ilyen műveleteket sokkal könnyebben el tudnék végezni.

Az ironikus hangnemért elnézést kérek, remélem, érthető, mire szerettem volna célozni.
99

Úgy vélem, elkerülte a

bamegakapa · 2014. Szep. 10. (Sze), 15.42
Úgy vélem, elkerülte a figyelmedet, amit az arany középútról írtam.
101

Nem kerülte el. Számomra az a

Hidvégi Gábor · 2014. Szep. 10. (Sze), 15.53
Nem kerülte el. Számomra az a középút, amit írtam, hogy csak annak látszódjék a címsor, aki kezd is vele valamit (mint például teljesképernyős módban).
103

Akkor itt be is fejeztük :).

bamegakapa · 2014. Szep. 10. (Sze), 15.56
Akkor itt be is fejeztük :). Neked így tetszik, nekem úgy tetszik, ezen felesleges vitatkozni.
84

A HTML5-öt meg a többit ne

Hidvégi Gábor · 2014. Szep. 10. (Sze), 13.41
A HTML5-öt meg a többit ne keverjük ide, az teljesen más téma :). A fejlesztő dolgát sem hülyeség megkönnyíteni, mindenki által ismert okokból, de ezt ott elegen kifejtették, igen jól.
Úgy gondolom, hogy vannak prioritások. Fontosabbnak tartom, hogy előbb azokkal a problémákkal kell foglalkozni, ami a felhasználókat érinti (jelen esetben például a hatékonyabb keresés), és ha már mindet megoldottuk, akkor lehet olyanokat elővenni, mint a csicsázás vagy a forrófejű fejlesztők fenekének fékevesztett fényesítése. Cserébe mintha pont fordítva lenne.
87

A HTML5-ről szerintem nem sok

inf · 2014. Szep. 10. (Sze), 14.09
A HTML5-ről szerintem nem sok fogalmad lehet.

Az olyan elemek, mint nav vagy section könnyebb gépi feldolgozást tesznek lehetővé, ami könnyebb kereshetőséget és mondjuk látás sérülteknél könnyebb felolvasást jelentenek.

Van továbbá egy csomó olyan elem, amit régebben flash-el, vagy silverlight-al lehetett csak használható módon megoldani, most viszont a HTML részei lettek, így nem kell külső plugin, hogy lejátsz egy videot vagy hangot, tegyél alá feliratot, stb... A grafikus elemek, mint az svg és a canvas meg tetszőleges, az oldalhoz kapcsolódó vektorgrafika és egyéb grafikai elem beágyazását teszik lehetővé. Szóval például ahhoz, hogy egy játékot írj webre, már nem kell többé flash, bőven elég a canvas. És ez akár az olyan 3d játékokra is vonatkozik, mint pl a quake vagy a doom (az újakat nem ismerem), nem csak a gagyi 2d átlag flash megoldásokra.

A hatékonyabb keresést már rég megoldották RDFa-val, annyi a probléma, hogy az átlag fejlesztőnek fogalma sincs arról, hogy mi az, hogy RDF, linked data, vagy RDFa, így nem is használja. Született emelett még egy csomó másik megoldás is, microdata, microformats, stb... Bármelyiket lehet használni, ha valaki jól kereshető oldalt akar csinálni.
91

Az általad felhozott érvekről

Hidvégi Gábor · 2014. Szep. 10. (Sze), 15.06
Az általad felhozott érvekről kis gondolkodás után beláthatod, hogy falsok, és csak a "geek"-ek számára fontosak (2009-ben a flash elterjedtsége 98%-os volt, ami azt jelenti, hogy nagyjából 1,2 milliárd embert nem érdekelt, hogy plugint kell telepíteni).

A hatékonyabb keresést már rég megoldották RDFa-val, annyi a probléma, hogy az átlag fejlesztőnek fogalma sincs arról, hogy mi az, hogy RDF, linked data
Ez is csak arról szól, hogy a fejlesztők magukkal és a maguk kényelmével foglalkoznak, és nem a felhasználókkal, akikből egyébként élnek. Off, de az általad felsorolt technológiák túl bonyolultak (RDF[a]) vagy csak nagyon kevés adattípus van hozzájuk (microformat), és nem is várható el senkitől emiatt, hogy használják őket.
92

Kérlek, ha nem a témába illőt

inf · 2014. Szep. 10. (Sze), 15.07
Kérlek, ha nem a témába illőt írsz, akkor azt jelöld meg vagy rakd külön fórumszálba

Gondolom ezt magadnak írtad, mert te kezdtél el HTML5-ről beszélni, amikor teljesen más volt a téma.

Off, de az általad felsorolt technológiák túl bonyolultak (RDF[a]) vagy csak nagyon kevés adattípus van hozzájuk (microformat), és nem is várható el senkitől emiatt, hogy használják őket.


Mint te is írtad senkit nem érdekel a fejlesztők kényelme. Ha nem tudnak megtanulni létező, google által támogatott, és egyébként jól működő technológiákat, akkor jobb, ha másik állást keresnek maguknak.

Az általad felhozott érvekről kis gondolkodás után beláthatod, hogy falsok, és csak a "geek"-ek számára fontosak (2009-ben a flash elterjedtsége 98%-os volt, ami azt jelenti, hogy nagyjából 1,2 milliárd embert nem érdekelt, hogy plugint kell telepíteni).


2010-ben a flash elterjedtsége 1% volt. (Nekem sem muszáj hivatkozást írni, hidd el bemondásra.)

A canvast és svg-t egyáltalán meg sem említetted. Gondolom nehéz ellenük bármit érvelni. A pluginok közül talán a silverlight ütötte meg azt a szintet, amit képviselnek, a flash valószínűleg a közelében sem volt, bár ez csak benyomás, nem használtam ténylegesen egyiket sem.

az általad felhozott érvekről kis gondolkodás után beláthatod, hogy falsok


Nem tudom nálad hogy megy ez, de általában a vitáknál érvelni szoktak, nem azt bizonygatni, hogy kis gondolokodással majd találsz a saját álláspontod ellen érveket... Dehát az ember mindig tanul valami újat. Az általad felhozott érvekről kis gondolkodás után beláthatod, hogy falsok...
100

2010-ben a flash

Hidvégi Gábor · 2014. Szep. 10. (Sze), 15.47
2010-ben a flash elterjedtsége 1% volt. (Nekem sem muszáj hivatkozást írni, hidd el bemondásra.)
Itt 96 és 99% közötti penetrációról írnak, de a google-ben te is rákereshetsz, hasonló adatokat fogsz találni. Ma már csak 83%.

Gondolom ezt magadnak írtad, mert te kezdtél el HTML5-ről beszélni, amikor teljesen más volt a téma.
Olvasd el akkor ismét, mit írtam, a HTML5-öt mint hasonló példát hoztam fel.

Ha nem tudnak megtanulni létező, google által támogatott, és egyébként jól működő technológiákat, akkor jobb, ha másik állást keresnek maguknak.
RDF(a)-t kutya nem fog használni, mert túl bonyolult, mint ahogy te sem integrálással számítod ki egy négyzet területét. A microformat hiába támogatott a google által, ha nagyon korlátozott az elemkészlete.

A canvast és svg-t egyáltalán meg sem említetted.
A flash kiváltja a canvas, az svg, a video és audio elemet, ráadásul az Actionscript jóval fejlettebb, mint a JS. Szóval eléggé visszalépés az egész. A flash azután lett kegyvesztett, miután az Apple azt mondta, hogy tovább nem támogatja. Előtte nem zavart senkit sem.
106

Olvasd el akkor ismét, mit

bamegakapa · 2014. Szep. 10. (Sze), 16.11
Olvasd el akkor ismét, mit írtam, a HTML5-öt mint hasonló példát hoztam fel.


Továbbra sem értem, hogy jött oda a HTML5. A te fejedben bizonyára legitim és létező a kapocs, ezzel nem is tudok mit tenni. Kértem is, hogy ne menjünk el ebbe az irányba.

A flash azután lett kegyvesztett, miután az Apple azt mondta, hogy tovább nem támogatja. Előtte nem zavart senkit sem.


Engem zavart. A HTML5 végre lefektetett egy rakás olyan dolgot, amit már nagyon régen le kellett volna. Nem mondom, hogy kiválóan sikerült, de már ideje volt.
112

RDF(a)-t kutya nem fog

inf · 2014. Szep. 10. (Sze), 18.50
RDF(a)-t kutya nem fog használni, mert túl bonyolult


Attól, hogy nem vetted a fáradságot, és szántál rá egy napot, hogy megtanuld, még nem bonyolult. Sima RDF kötéseket csapsz hozzá a tartalomhoz néhány attribútummal ill. URI-k használatával. Egyébként pont te érveltél azzal a HTML5 újításai ellen, hogy tök feleslegesek, és csak a szoftverfejlesztők kényelmét szolgálják. Akkor nem értem, hogy miért panaszkodsz...


Jelenleg 300 millióból olyan 3 millió domain használ microdata-t vagy RDFa-t. Mindkettő körülbelül ugyanazt tudja, az arány fele-fele. A microdata használata egyre növekszik, és valószínűleg idővel ki fogja szorítani, mert valamivel egyszerűbb scope-al használni a vocab-ot, és nem mindig kiírni a névteret.


A flash azután lett kegyvesztett, miután az Apple azt mondta, hogy tovább nem támogatja. Előtte nem zavart senkit sem.

Engem mindig is zavart, mert a webre szeretnék fejleszteni, és nem egy pluginra. Ezért is örülök a HTML5-nek, meg annak, hogy végre belátták a böngésző gyártók, hogy a pluginek és saját külön formátumok készítése nem járható út a weben, és helyettük a HTML-t kell fejleszteni, mert azt kénytelen az összes böngésző támogatni. Ez legjobban a silverlight-nál látszott meg, a microsoft beleölt egy csomó energiát, de nem tudta keresztülverni, hogy minden böngésző alapból támogassa. De ugyanígy voltak próbálkozások firefox részéről is pl xforms-al, stb...
113

Ha valóban egy nap lenne a

Hidvégi Gábor · 2014. Szep. 10. (Sze), 19.29
Ha valóban egy nap lenne a megtanulási ideje, akkor nyilván mindenki használná. Emellett a különböző névtereket (objektumtípusokat) neked kell összevadászgatnod, ráadásul összeszemeteli a HTML-t. A mai fejlesztőknek a <nav> begépelése is elég, az <ul role="nav">-ot már sokallják, akkor a <span rel="foaf:interest" resource="urn:ISBN:0752820907">-tól menekülni fognak. Amíg nem találnak erre egy olyan faék egyszerűségű szintaktikát, mint amilyen a HTML, addig nem fog működni a dolog.

A microdata használata egyre növekszik, és valószínűleg idővel ki fogja szorítani, mert valamivel egyszerűbb scope-al használni a vocab-ot, és nem mindig kiírni a névteret.
Erről beszélek.

végre belátták a böngésző gyártók, hogy a pluginek és saját külön formátumok készítése nem járható út a weben
A Google nem egészen így gondolja
114

Amíg nem találnak erre egy

inf · 2014. Szep. 10. (Sze), 21.33
Amíg nem találnak erre egy olyan faék egyszerűségű szintaktikát, mint amilyen a HTML, addig nem fog működni a dolog.


Csak megjegyzésként teszem hozzá, hogy a microdata-hoz is ugyanúgy össze kell vadászni a vocab-ot, szóval semmivel sem egyszerűbb ilyen szempontból.

Nem fognak találni hozzá, mert az URI-t mindenképp meg kell adni, mint erőforrás azonosítót. Nélküle gépileg nem feldolgozható a dolog, mert a kereső csak szavakat lát, de nem képes összerakni a jelentésüket, mert nem ismeri a kontextust. Majd ha lesz mesterséges intelligencia, akkor más lesz a helyzet, de jelenleg csak ez működik.

A Google nem egészen így gondolja


A google próbálkozhat mással, de nem fog összejönni neki. Az elmúlt 25 év legalábbis ezt mutatja.
120

HG ne már...

Gixx · 2014. Szep. 15. (H), 15.29
A Google nem egészen így gondolja


Legalább annyit tegyél meg legközelebb, hogy a keresőeszközökben bekapcsolod "Az elmúlt hónapban" szűrőt. Nekem az első oldalon 2012 júliusi a legfrissebb link. Az IT-ban ez már a történelem kategória manapság.
115

Engem mindig is zavart, mert

Hidvégi Gábor · 2014. Szep. 11. (Cs), 08.42
Engem mindig is zavart, mert a webre szeretnék fejleszteni, és nem egy pluginra. Ezért is örülök a HTML5-nek, meg annak, hogy végre belátták a böngésző gyártók, hogy a pluginek és saját külön formátumok készítése nem járható út a weben, és helyettük a HTML-t kell fejleszteni, mert azt kénytelen az összes böngésző támogatni.
És akkor megint visszakanyarodtunk a kiindulóponthoz, hogy a fejlesztők azt hiszik, körülöttük forog a világ. Emiatt hoztam fel példának a HTML5-öt, mert minden mondatodban azzal érvelsz, hogy neked hogyan lesz jobb:

- "webre szeretnék fejleszteni, nem pluginra"
- "Az olyan elemek, mint nav vagy section könnyebb gépi feldolgozást tesznek lehetővé, ami könnyebb kereshetőséget és mondjuk látás sérülteknél könnyebb felolvasást jelentenek." - a role attribútumok ezt már évekkel a HTML 5 megjelenése előtt tudták
- "Szóval például ahhoz, hogy egy játékot írj webre, már nem kell többé flash"

És hol maradnak, kérem, a felhasználók? Nekik nem mindegy, hogy egy grafikai elem natív vagy plugin? Erre hoztam a példát, hogy 2009-ben 98% számára mindegy volt. Számukra milyen előnyöket hoz a HTML5? Pedig belőlük élünk, hisz ők veszik meg a megrendelőink termékeit, így közvetve tőlük kapjuk a fizetésünket. Az általad felhozott RDFa és microformats 1% alatti elterjedtsége nem túl kielégítő. Ha valóban hasznosak, mert hatékonyabb keresést tesznek lehetővé, akkor miért nem ezek fejlesztésével foglalkozunk?
117

Én, mint felhasználó

Gixx · 2014. Szep. 15. (H), 15.12
Én, mint FELHASZNÁLÓ (mondhatnám úgy, hogy iUser) örülök a HTML5-nek, ugyanis a mobilomon hasznát veszem:

* szeretem a <video>-t, mert tudok videót nézni Flash nélkül is: kezdetben ugyan volt flash, de az akkori technológiai szinten megette, sőt felfalta a telefont, és egy kőkorszaki kavicsot varázsolt belőle. Ma már lehet, hogy jobban bírnák, de nem hiányzik senkinek se.

* szeretem az <input type="number">-t, mert egyből a numerikus billentyűzet jön fel, ha csak számot kell begépelni (pl irányítószám)

* szeretem az <input type="email">-t, mert megjelenik a @ a billentyűzeten, nem kell bemenni a speciális listára.

* szeretem a többi HTML5 inputot is, mert, ha az oldalon jól van használva, akkor FELHASZNÁLÓKÉNT sokkal könnyebben tudok böngészni.

* ha látássérült lennék, és ismernék jó felolvasó programokat, amik ismerik a HTML5-öt, akkor FELHASZNÁLÓKÉNT biztosan örülnék a sok új szemantikus csodának, mert a program helyén tudná kezelni a dolgokat (navigáció, fejléc, tartalom stb.) és nem venné egy kalap alá a menüt és a tartalomba helyezett felsorolást, mert mindkettő <ul><li>

FEJLESZTŐKÉNT szeretem a HTML5-öt, mert

* a sok új tagre sokkal egyszerűbben tudom ráültetni a CSS-t és a JS-t is

* könnyebb olyan oldalakat készíteni, ami sokkal több ember igényeit kielégíti (még a mobilozó látássérültekét is)...
118

* szeretem az <input

Poetro · 2014. Szep. 15. (H), 15.18
* szeretem az <input type="number">-t, mert egyből a numerikus billentyűzet jön fel, ha csak számot kell begépelni (pl irányítószám)

Azért vannak hátrányai is. Ha ugyanis a szám 0-val kezdődik, akkor az (mármint a 0) nem kerül(t) elküldésre. Ezek kívül, van más nem kívánatos tulajdonsága is a "number"-nek, például növelés/csökkentés gombok, amivel növelni, csökkenteni lehet az értéket, és egyes böngészők másként kezelik ezt (fel/le gombok és egérgörgő esetleg növelik illetve csökkentik az értéket). Sajnos sokszor marad a "tel".
119

akkor lehet, nem number-t használnak

Gixx · 2014. Szep. 15. (H), 15.24
... a lényeg, hogy amikor kell, akkor csak számokat gépelek :)

Mondjuk az nem lenne hátrány, ha JS-ből definiálhatnád a keyboard layoutot egy-egy inputhoz :)

Azaz helyesbítek. Ismerve magamat, és sok sok feljelsztő kolléga (a múltban és jelenben) munkamódszerét, valószínűleg néhány esetben hátrány lenne. A felhasználó számára. Aztán jönnek a hotfix-ek, meg a frissítések, amíg végül vagy visszaáll minden a rendszer által támogatottra, vagy csak szimplán működni fog :)
121

- Korábban volt flash és

Hidvégi Gábor · 2014. Szep. 15. (H), 16.28
- Korábban volt flash és actionscript, most van audio, video, canvas és javascript, így most az utóbbi akasztja ki a gépet, a mai divatnak megfelelően a jQuery és az átlag 15, külön-külön betöltött plugin. Ha konpatibilis szeretnél lenni a lehető legtöbb klienssel, akkor legalább két-három formátumban fel kell tenni a videót, míg korábban elég volt egy swf-ben feltenni.
- A különböző új input type-ok bár biztosan hasznosak, de nem indokolnak főverzióváltást.
- N-szer leírtam, de leírom n+1-edszer is szívesen: ha tényleg érdekel, hogy sérültek is megnézhessék az oldalad, évekkel a HTML 5 előtt ott volt az XHTML role attribútuma, ami, ha utánajársz, ráadásul jóval több lehetőséget biztosít, mint az új tag-ek. Kíváncsi vagyok, hogy amikor ezt valaki felhozza mint érvet a HTML 5 mellett, vajon ezt az attribútumot használta-e korábban, és használja-e azokat az értékeket, amire nincs HTML tag? Van egy olyan érzésem, hogy 99%-ban a válasz nem lenne.

A legegyszerűbb leellenőrizni a dolgot, ha előveszel egy-két 2006 körüli html kódot, és ha benne vannak a role attribútumok, akkor már azidőtájt is érdekelt a téma. Ha nem, akkor meg ez az egész nem más, mint disszonanciacsökkentés (ti. az új tag-ek mellett való érvelés).

De ha már a kisebbségnél tartunk, kíváncsi lennék, hogy vajon az 1-2%-nyi látogatót is ugyanígy támogatod, akik kikapcsolt javascripttel érkeznek az oldalaidra, azaz számukra is elérhető minden szolgáltatás? Mert ők nagyjából ugyanannyian vannak átlagosan, mint a sérültek.
- $('.article') helyett $('article') ez valóban jóval egyszerűbb, nem kell annyit gépelni

Amiket felhoztál érvként, az vagy elhanyagolható számú felhasználót érint vagy pedig csak kicsit lesz tőle kényelmesebb a böngészés. De a legfontosabb dologgal, annak a problémának a megoldásával nem foglalkoztál (sem te, sem a HTML kitalálói), ami minden felhasználót érint, méghozzá a kereshetőség javítása. És ha azt vesszük, hogy ezen minorális javulást hozó fejlesztések bevezetése is hány évet vett igénybe, akkor abból kiszámolható, hogy itt évtizedeket, évszázadokat vesz majd igénybe, hogy normálisan kereshető legyen a net, köszönhetően a fejlesztők kényelemszeretetének.
122

Kíváncsi vagyok, ha az

Joó Ádám · 2014. Szep. 15. (H), 17.05
Kíváncsi vagyok, ha az általad vizionált szabványok megszületnének, hogyan vennéd rá a használatukra azt az iparágat, amelyiken nem sikerült keresztülverni az XHTML-t. Tényleg érdekelne a válaszod.
123

Nem rávenni kellene őket,

Max Logan · 2014. Szep. 15. (H), 18.44
Nem rávenni kellene őket, hanem nekik közösen (!!!) kellene megalkodni úgy, hogy minden, de tényleg minden benne legyen, ami felmerült ötletként, és értelme van, életszerű az igény (akár fejlesztői, akár felhasználói oldalról).

És ez alapján pedig közösen (!!!) lenne megírva az általam már többször említett render (és JS) engine, amit csak használni kellene a böngészők gyártóinak. Innentől mindjárt ketté is válik a böngészőket fejlesztők és az engine-eket fejlesztők tábora, továbbá könnyű dolga lenne a frontend fejlesztőknek, ugyanis, ha a validator azt mondja, hogy ok a HTML vagy a CSS, akkor minden, azaz minden eszközön, platformon egyformán jelenne meg a site. Nem kellene tesztelni millió helyen, mert az egyetlen közös engine miatt borítékolt, hogy bárhol ugyanazt látom.

Ez az egyetlen értelmes, és járandó út. Ehhez viszont az kellene, hogy értékközpontúan gondolkodjanak a piac szereplői. Ide viszont fel kell nőni, de nem úgy néz ki, hogy képesek lennének a közeljövőben megugrani ezt a lécet a fiúk és lányok... 5 év alatt meg lehetne reformálni a webfejlesztést és a webet magát, mert az emberiség képes rá, csak hát ugye az érdekek...
124

Ez az egy renderer ugyanolyan

Joó Ádám · 2014. Szep. 15. (H), 18.47
Ez az egy renderer ugyanolyan ötlet, mint a kommunizmus. És ugyanazért nem jó.
127

Ennél jobb megoldás nincsen.

Max Logan · 2014. Szep. 15. (H), 19.23
Ennél jobb megoldás nincsen. Eljut majd ide az emberiség, de addig még hosszú az út.

Kár ide keverni egyéb ideológiákat, mert a történet nagyon egyszerű. Adott egy valami, amit webnek hívunk. Adott egy rakás felhasználó, akik igényelnek valamit. Adott egy rakás fejlesztő és piaci szereplő, aki szolgáltatna. Adott számos jó koponya, kiváló ötletekkel. Adott egy együttműködő közösség, aki meghatározza, hogy mi az, aminek értelme van a gyakorlatban. Vagyis mi az, amire lehet értékteremtő megoldásokat építeni. Gondolok itt a HTML, a CSS és a JS lehetőségeire. Hogy aztán a valóságban ki használja x tag-et, CSS tulajdonságot, JS varázslatot, az már egy másik lapra tartozik. Aki éppen nem ért egyet egy ötlettel, de abból kára nem származik, hogy megvalósul, annak nem fáj a feje attól, hogy bekerül az engine-be.

Nem olyan bonyolúlt ez, csak az érték nézőpontjából kell megközelíteni a munkát, és az együttműködés. Mi az érték? Ami olyan lehetőséget teremt, amivel másoknak segíteni lehet, szintet lehet lépni. Ha egy megoldás jó a programozónak, és nem sérül a felhasználói teljesítmény, akkor kódolják le. És viszont.

Azt elfogadom, hogy nem tudtok hinni ebben a dologban, de mint ahogyan az egykulcsos adószrendszernél igazságosabb nincsen, úgy ennél a megközelítésnél sincsen jobb. Hogy itt és most az emberiség legnagyobb része alkalmatlan a megvalósításra, egy másik történet.
129

„Ennél jobb megoldás nincsen.

Joó Ádám · 2014. Szep. 15. (H), 20.01
„Ennél jobb megoldás nincsen. Eljut majd ide az emberiség, de addig még hosszú az út.”

– Vlagyimir Iljics Uljanov

Te szeretnél egy olyan társadalomban élni, ahol nincsen választásod?
132

Miben nem lenne választásod?

Max Logan · 2014. Szep. 15. (H), 20.09
Miben nem lenne választásod?
134

Motor-fejlesztőként semmiben

Joó Ádám · 2014. Szep. 15. (H), 20.34
Motor-fejlesztőként semmiben nem volna választásom, amit a projekt vezetői megszabnak.

Böngésző-fejlesztőként rám volna kényszerítve egy motor, annak funkciói, felülete, technológiája, teljesítménye.

Webfejlesztőként ki lennék szolgáltatva egy monopol helyzetben lévő gyártónak.

Felhasználóként ki lennék szolgáltatva egy monopol helyzetben lévő gyártónak.

Láttuk már azt, amit javasolsz, a motor neve Internet Explorer 6 volt.
136

Na itt a probléma. Nem érted,

Max Logan · 2014. Szep. 15. (H), 20.46
Na itt a probléma. Nem érted, hogy miről beszélek. Nincsen gyártó. Egy nagy közösség van, ami érték mentén ötletel, majd kódol.

Ha tetszik, OpenSource engine-t írna a világ legjobb programozóinak csapata, azzal a szent céllal, hogy a lehető legjobb engine készüljön el. Nincsen teljesítmény probléma, mert ha van, akkor azt megoldja seperc alatt a csoport, ami magába tömörít több 100 vagy 1.000 kiválónál-kiválóbb programozót a világ minden pontjáról.

Ne piaci értékrenddel közelíts. Itt arról van szól, hogy pénzorientáltságtól függetlenül építünk egy alapot, amire aztán mindenki építheti a megoldásást, amiért pénzt kér(het).
140

Egy nagy közösség van, ami

Joó Ádám · 2014. Szep. 15. (H), 21.05
Egy nagy közösség van, ami érték mentén ötletel, majd kódol.


Ki vezeti ezt a közösséget?

Ha tetszik, OpenSource engine-t írna a világ legjobb programozóinak csapata, azzal a szent céllal, hogy a lehető legjobb engine készüljön el.


Ki dönti el, hogy ki kerülhet be ebbe a csapatba?

Nincsen teljesítmény probléma, mert ha van, akkor azt megoldja seperc alatt a csoport, ami magába tömörít több 100 vagy 1.000 kiválónál-kiválóbb programozót a világ minden pontjáról.


Ha egy megoldásról megoszlanak a vélemények, hogyan dől el, hogy melyik lesz kivitelezve?

Ne piaci értékrenddel közelíts. Itt arról van szól, hogy pénzorientáltságtól függetlenül építünk egy alapot, amire aztán mindenki építheti a megoldásást, amiért pénzt kér(het).


Hogy jön ide a pénz? Én egy szóval sem beszéltem pénzről.
137

Senkinek nem lenne senki

Max Logan · 2014. Szep. 15. (H), 20.51
Senkinek nem lenne senki kiszolgáltatva, mert közös érdek mentén (a lehető maximum megteremtése) egymásért tennének az emberek.

A technológia egy másik kérdés, most arról nem beszélünk. Ha más kódbázist kíván meg az ARM rendszerrel üzemelő mobil, mint az x86-tal üzemelő, akkor lesz két különböző kódbázis, de 100%-ban azonos algoritmusok futnak le a háttérben. Ez ma nem garantált, ebből van a mérhetetlen nagyon szopás a webfejlesztésben (is).
141

Senkinek nem lenne senki

Joó Ádám · 2014. Szep. 15. (H), 21.11
Senkinek nem lenne senki kiszolgáltatva, mert közös érdek mentén (a lehető maximum megteremtése) egymásért tennének az emberek.


Mi a közös érdek? Úgy gondolod, hogy mindenki érdeke ugyanaz? Hogy különböző embereknek nincsenek különböző igényeik?

A technológia egy másik kérdés, most arról nem beszélünk.


Kénytelenek vagyunk.

Ha más kódbázist kíván meg az ARM rendszerrel üzemelő mobil, mint az x86-tal üzemelő, akkor lesz két különböző kódbázis, de 100%-ban azonos algoritmusok futnak le a háttérben.


Ugye tisztában vagy vele, hogy ez lehetetlen? Márpedig két különböző kódbázissal ugyanott tartasz, ahol most, hogy nem lehetsz biztos a megjelenésben.
143

Mi a közös érdek? Úgy

Max Logan · 2014. Szep. 15. (H), 21.28
Mi a közös érdek? Úgy gondolod, hogy mindenki érdeke ugyanaz? Hogy különböző embereknek nincsenek különböző igényeik?
A lehető maximum elérése, minden olyan lehetőség megteremtése, aminek gyakorlati haszna, értékteremtő faktora van. Ha egy irányba nézünk, akkor az érdekek azonosak (a maximum megteremtése). Hogy más kell nekem, és más neked, nem probléma. Megvalósul mindkettő, te használod az egyik HTML/CSS megoldást, én meg a másikat.


Ugye tisztában vagy vele, hogy ez lehetetlen? Márpedig két különböző kódbázissal ugyanott tartasz, ahol most, hogy nem lehetsz biztos a megjelenésben.
A technológiai kivitelezést meghagyom a legprofibb szakembereknek. Kihívás, amit meg kell oldani! Ismered a mondást, hogy mindenki úgy gondolta, lehetlen, aztán jött valaki, aki erről nem tudott, és megvalósította... Az a baj, hogy az emberek gondolkodását korlátok közé szorította a globális rendszer, és az ember maga.

De ez már messze vezet, gondolataim a spiritualitásból táplálkoznak, aki pedig ezen értékrendet nem tudja magáénak vallani, soha nem fogja megérteni az irányt, amerre én nézek...
146

A technológiai kivitelezést

Joó Ádám · 2014. Szep. 15. (H), 21.41
A technológiai kivitelezést meghagyom a legprofibb szakembereknek. Kihívás, amit meg kell oldani!


A technológiai szakemberek pedig erre ingerülten kezdenek beszélni csalán és nemiszervek vonatkozásában :)
148

Vannak elméleti és nem

Max Logan · 2014. Szep. 15. (H), 21.54
Vannak elméleti és nem elméleti matematikusok, fizikusok, stb. Én meg tudok fogalmazni dolgokat, de nem dolgom sokszor pl. a kivitelezés vagy az üzemeltetés. Mindenkinek megvan a maga dolga a világban, de a legtöbben (még) nem kutatták ki (vagy soha nem fogják). Én érzem, hogy milyan dolgaim vannak itt és most. Az egyik az, hogy kimondjam, amit mások nem tudnak/akarnak/félnek/stb.
150

Az elméleti és alkalmazott

Joó Ádám · 2014. Szep. 16. (K), 00.17
Az elméleti és alkalmazott matematika közti viszony nem azonos az idealizmus és a való világ közti viszonnyal.

Néhány évvel idősebb vagy nálam, Norbi, de úgy érzem, hogy úgy gondolkodsz, mint én pont ugyanennyi évvel fiatalabban.

Ha jobbá akarod tenni a világot, akkor először el kell fogadd, hogy hogyan működik.
155

Az, hogy fizikia minőségem

Max Logan · 2014. Szep. 16. (K), 07.38
Az, hogy fizikia minőségem hány éves, mit sem számít. Úgy gondolkodom, hogy ignorálom azokat a dolgokat a világból, melyekre nincsen szükségem ahhoz, hogy az új világot megalapozzam. Nem fogadom be azokat az energiákat, melyek a jelenben – nem a megélendő pillanat értelmében –, avagy a múltban tartanának. Ezért tűnik úgy, hogy nem fogadom el a valóságot.

Én a távolba tekintek, olyan messzire, ahova a legtöbb ember nem képes. Ez a mindennapi életben is jelen van. Amikor megkeresnek egy projecttel, ők még csak az ötletet fogalmazzák meg, én már azonnal látom, hogy hova juthat el 1-3-5 év távlatában, azonnal megfogalmazon a nagyobb léptékű összefüggéseket, kapcsolódási pontokat (mit lehet kihozni a projectből, amire az ötletgazda nem is gondolt; pl. társadalmi szerepvállalás témaköre, pedig ő pénztermelő gépezetet építene).

Nem dolgom a múlttal és jelennel foglalkozni, én az vagyok, aki a távoli jövőt alapozom. Fény vagyok az éjszakában, de ezt sokan nem értik tudasan, de azt a pozitív energiát, amit közvetítetek, tudattalanul is felfogják, beépítik. Számos visszajelzést kaptam már ezzel kapcsolatban.

Megosztó vagyok, gondolataim, nézeteim is azok, közlésmódom kritikus, biztosítékot kicsapó. De ma már látom, hogy ez is az egyik feladatom, hogy piszkáljam az embereket, hogy a komfort zónából kilépjenek. Van akit ez nagyon irritál és nem történik semmi, van akinél elindítja a folyamatot, mert már kellően készen van.

Példaként a Mátrix trilógiát tudom hozni. A való életben (ami virtuálisabb, mint azt a legtöbben gondolnák) éppen az történik, mint a filmben. Egy kis (de egyre növekvő) csoport azon dolgozik, hogy minél többen ébredjenek. A gát már átszakadt, a nagy(nak tűnő hatalmi) rendszer nem képes már visszatartani az új kor eljövetelét. A kérdés csak az, hogy mennyi időbe telik az új világ megteremtődése.

Nem dolgom tehát azzal foglalkozni, hogy mi van, mert az a múlt következménye. Én itt és most a jövőt alapozom... Szoktam volt mondani: nem érdekel, hogy mi van, csak az, hogy mi lehet(ne).
157

Azt hiszem, Ádám említette

H.Z. · 2014. Szep. 16. (K), 08.45
Azt hiszem, Ádám említette az anarchiát. Sajnis igaza van: az a (valójában sok) kis csoport, tudatosan vagy sem, de azon dolgozik, hogy anarchia legyen. Szívesen tennék ide egy vigyorgó smiley-t de egyáltalán nem tartom humorosnak. :(
165

Aki valamennyire is

Max Logan · 2014. Szep. 16. (K), 13.51
Aki valamennyire is foglalkozik a spiritualitással, pontosan tudja, hogy mire gondolok (aki nem, az nem fogja érteni gondolataimat). Amikor a szeretet energia, a legtisztább pozitív töltés dolgozik, az szervezi a dolgokat, akkor nincsen anarchia. A mostani berendezkedések, rendszerek valóban megszűnnek létezni, de nem anarchia lesz, hanem békés együttélés. Erre jelenleg az emberiség nem érett, de efelé tartunk... Hogy milyen gyorsan érünk oda, az sok mindentől függ. Nem is akarom megjósolni időben, csak tudom, ezért a jobb, szebb, élhetőbb világért dolgozunk. Ki így, ki úgy. Mindenkinek megvan a maga szerepe, és a maga útja, amit játszania és járnia kell.

Idézet a wikiszotar.hu-ról:
Anarchia: A rendezettség hiánya, amikor nincs semmilyen biztos pont, amihez viszonyítani lehetne; fejetlenség, zűrzavar. Az anarchiában nem működik semmilyen ésszerű rendszer.
Amiről én beszélek, ott teljes a rend, van rendszer, csak ezt nem külső, hanem belső, lelki „egyezmények”, a legtisztább létenergia szavatolja. Aki a múltba réved, a jelenben dagonyázik, annak ez a lehetőség valóban utópisztikus.
128

Nem látom be, hogy miért jobb

Max Logan · 2014. Szep. 15. (H), 19.28
Nem látom be, hogy miért jobb az, hogy csoportok külön dolgoznak, aztán később meg harcolnak egymással, hogy a másik a levédett megoldást miért is használta fel, vagy mivel nem védhető az ötlet, mások is megvalósítják, mint az, hogy ezek az emberek együtt dolgoznak, a közös cél mentén. Ja, hogy nem az a cél, hogy jót tegyünk (a másikkal), hanem, hogy egós hatalmi játszámákat játszunk, és virtuális vagyonokat építsünk?!
130

Nem látom be, hogy miért jobb

Joó Ádám · 2014. Szep. 15. (H), 20.04
Nem látom be, hogy miért jobb az, hogy csoportok külön dolgoznak


Úgy gondolod, hogy a szabad verseny nem jó?
131

Azt gondolom, hogy a szabad

Max Logan · 2014. Szep. 15. (H), 20.08
Azt gondolom, hogy a szabad versenyben jelenleg egymásnak feszülő energiák egyesítése hatékonyabb, gyorsabb, produktívabb munkát eredményezne. A szabad verseny alapja, hogy ki gyűjti be az erőforrásokat. Az én megközelítésem pedig arról beszél, hogy a humán és egyéb erőforrásokat egyesítsük, a keletkezett értéket pedig adjuk közzé, és akinek kell, vegyen belőle. Érték teremtése vs. vagyon és hatalom magunkhoz csoportosítása. Egymásért, nem pedig egymás ellen kell tennünk.
133

Megdöbbentő, hogy negyven év

Joó Ádám · 2014. Szep. 15. (H), 20.23
Megdöbbentő, hogy negyven év szocializmus után még mindig van, aki pont ugyanazokat a gondolatokat hangoztassa. Vonatkoztass el a saját értelmezésedtől, és olvasd vissza, amit írsz! O.O
135

Őszinte leszek, nem

Max Logan · 2014. Szep. 15. (H), 20.38
Őszinte leszek, nem érdekelnek a politikai nézetek, nem is ismerem őket, nem is nagyon szeretném megismerni őket; a politika az egyik legnegatívabb energia.

Egy dologban hiszek: összefogás, értékteremtés.

Az összefogásra ékes példa volt 1,5 éve a március 15-ei hóvihar. Megmozdult az ország, csak azóta ismét elfelejtették, hogy mit és hogyan csánáltak...

Értékteremtés pedig az, amikor valami jobb lesz, mint volt, több ember fér hozzá dolgokhoz, egyszerűbb, minőségibb az élet, stb.

Az egy render engine mind a böngészőgyártók életét, mind az enegine fejlesztők életét, mind pedig a frontend fejlesztők életét megkönnyítené. Előbbi csportnak nem kellene erőforrásokat allokálni az engine-ekre, második csoport fókuszálhatna kizárólag az engine-re, az utolsó csoport pedig szabvány szerint ír kódot, és ha nem teszelni böngészőben, akkor is 100% biztonsággal tudja, hogy a kódja azt csinálja, amit csinálnia kell.
138

Őszinte leszek, nem

Joó Ádám · 2014. Szep. 15. (H), 20.55
Őszinte leszek, nem érdekelnek a politikai nézetek, nem is ismerem őket, nem is nagyon szeretném megismerni őket; a politika az egyik legnegatívabb energia.


Furcsa, mert szinte csak politikai hozzászólásaid vannak.

A politika az emberi történelem meghatározója, a történelem pedig az élet tanítómestere. Én ajánlom, hogy kezdd el tanulmányozni, és biztos vagyok benne, hogy felül fogod vizsgálni az emberekről és a társadalomról alkotott nézeteidet.

Utópiákról álmodsz, és a történelem megmutatta, hogy valahányszor emberek nekifogtak egy utópia megvalósításának, jó esetben nem lett belőle semmi, túl sokszor pedig a legsötétebb disztópia vált valóra.
142

Az a baj, hogy a

Max Logan · 2014. Szep. 15. (H), 21.12
Az a baj, hogy a gondolataimat a politikával azonosítod... Minden amit mondok, a legőszintébb segítő energiából táplálkozik.

A politikára az emberiségnek nincsen szüksége. Ma még jelen van, de már haldoklik...

Fogalmazzunk úgy, hogy nézeteim túlmutatnak az átlagember nézetein. Ez volt itt, és máshol az utolsó ilyen jellegű megnyilvánulásom. Az utóbbi évek során elég feedback-et kaptam, látom, hogy értékrendemet nem kell, nem is tudom megvitatni másokkal (mármint a nézeteimet nem értőkkel). Tennem kell, mit érzek, hogy dolgom tenni, és teszem mindezt a legtisztább pozitív, segítő, építő, teremtő energiából táplálkozva.
144

Az a baj, hogy a

Joó Ádám · 2014. Szep. 15. (H), 21.33
Az a baj, hogy a gondolataimat a politikával azonosítod...


Nem én azonosítom, a gondolataid politikai gondolatok. Amikor véleményt nyilvánítasz arról, hogyan kellene működjön a társadalom, akkor politizálsz.

Minden amit mondok, a legőszintébb segítő energiából táplálkozik.


Az, hogy politizálsz, ezt nem zárja ki.

A politikára az emberiségnek nincsen szüksége. Ma még jelen van, de már haldoklik...


Remélem, hogy nem, mert anarchiának hívják azt az állapotot, amihez a halála vezet.

Fogalmazzunk úgy, hogy nézeteim túlmutatnak az átlagember nézetein. Ez volt itt, és máshol az utolsó ilyen jellegű megnyilvánulásom. Az utóbbi évek során elég feedback-et kaptam, látom, hogy értékrendemet nem kell, nem is tudom megvitatni másokkal (mármint a nézeteimet nem értőkkel). Tennem kell, mit érzek, hogy dolgom tenni, és teszem mindezt a legtisztább pozitív, segítő, építő, teremtő energiából táplálkozva.


Mindig veszélyes, ha úgy érzed, hogy a gondolataid túlmutatnak másokén, és ha vitába szállnak veled, az azért van, mert nem értenek. Lehet, hogy tökéletesen értenek, egyszerűen csak nem értenek veled egyet. Persze, lehet, hogy tényleg neked van igazad, de ne felejts el kételkedni benne.

Ezen túl a leghelyesebb valóban az, ha teszed, amiről úgy gondolod, a legjobb – csak néha vizsgáld felül, amit teszel, mert csak egy életed van, és szar dolog túl későn jönni rá, hogy a grál valójában sosem létezett. (A felülvizsgálás vonatkozik az életek számáról alkotott véleményre is. Just in case.)
167

Remélem, hogy nem, mert

Max Logan · 2014. Szep. 16. (K), 17.02
Remélem, hogy nem, mert anarchiának hívják azt az állapotot, amihez a halála vezet.
Nem vezet. Csak odáig még hosszú út vezet. Csak az embereken múlik, hogy ez 500 vagy 5000 év lesz. Ha nyitott vagy a spiritualitásra, akkor ajánlom a vntv.hu-n publikált videó alapú beszélgetéseket.

Persze, lehet, hogy tényleg neked van igazad, de ne felejts el kételkedni benne.
Ezen túl a leghelyesebb valóban az, ha teszed, amiről úgy gondolod, a legjobb – csak néha vizsgáld felül, amit teszel, mert csak egy életed van, és szar dolog túl későn jönni rá, hogy a grál valójában sosem létezett. (A felülvizsgálás vonatkozik az életek számáról alkotott véleményre is. Just in case.)

Folyton megteszem, hogy megkérdőjelezem a saját nézeteim valódiságát. Aztán amikor elfeledek minden gondolatot, ami valójában ítélkezés, akkor ha békét érzek belül, jó úton vagyok. A belső visszajelző rendszerem (pl. intuíció) azt súgja, hogy jó úton játok. Ami pedig az életek számát illeti, nem hiszem, érzem és tudom, hogy nem egy van. (Minden energia, így hát mi magunk is. Az emberi létforma csak egy ruha, a lélek ruhája, azért, hogy meg tudja tapasztalni milyen az anyag.)
149

hangoztassa

Hidvégi Gábor · 2014. Szep. 15. (H), 21.55
hangoztassa
Ez azért sérti a fülemet : )

Mindkét oldal mellett lehet pro és kontra érveket felsorolni. Múltkor olvastam egy cikket, majd megkeresem és beküldöm blogmarkba, hogy 2014-re eljutottunk odáig, hogy a böngészők a szabványokat eléggé hasonlóan értelmezik, azaz ugyanaz a kód nagyjából ugyanúgy néz ki minden böngészőben. Innentől kezdve legfeljebb sebességben és kezelhetőségben van a legtöbb eltérés (bár a mai minimál UI-k mellett még itt se nagyon), és ennyi erővel lehetne akár egy motor is.

A másik oldalról nézve a verseny is jó, például múltkor olvastam, hogy Raspberry Pi-re hoztak ki Epiphany alapú böngészőt, márpedig az a hardver nagyon sovány.
152

Ez azért sérti a fülemet :

Joó Ádám · 2014. Szep. 16. (K), 00.59
Ez azért sérti a fülemet : )


Együttérzek. De kötőmódnak hívják :)
153

Nyelvész, grammar-nazi, szóval offtopic

H.Z. · 2014. Szep. 16. (K), 02.48
Nem vagyok biztos benne, hogy helyesen használtad.
A "... van aki ..." helyett szerintem inkább "... legyen aki ..." kellett volna.
Persze ez csak érzés, helyesírási szabályzattal nem tudnám alátámasztani. Az általad használt szerkezetbe inkább a "hangoztatja" illene. Szerintem.
(jelzem, nem is oly rég mondta "tudjukki" :D, hogy itt munka alapú társadalom lesz, ha beledöglünk - ő nem, csak mi - is ;) )
154

Most tényleg? Kísérjétek ki

Joó Ádám · 2014. Szep. 16. (K), 05.23
Most tényleg?

Kísérjétek ki barátaim a holtakat, és gyors lábakkal menjetek a sírokhoz, és figyelemmel tekintsetek körül: nemde elenyészik ott az ifjúság, s egyaránt elhervad minden életkor; ottan minden: por, hamu és féreg; ottan mély csend és hallgatás, és senki sincs, aki hangoztassa a zsoltárt: Alleluja!


– Halottvirrasztáskor

Nemzetünk — bármenynyire hangoztassa is egy pár „nagy hazafi“ a demokracia legszélesebb értelemben felfogott elveit — arisztokraticus érzelmü nemzet.


– Gróf Zichy Jenő levele gróf Károlyi Gyulához. Nemere. 1879. 65. sz.

A tanítóképzők tételénél Mócsy Antal visszatért erre az összetűzésre s megütődéssel konstatálta, Thaly fölszólalásának az volt az iránya, hogy itt vádként hangoztassa, hogy a katholikusoknak külön is kell a hazafiságot hangsulyozni.


– Mikszáth Kálmán: A kultusz-tárcza. Országos Hirlap, 1898, 55. sz.


A keresztyénség szellemétől való áthatottsága ellenére sem téved a szerző arra a tudományellenes álláspontra, hogy annak abszolút voltát hangoztassa, sőt miután rendszerint reámutat a vallások egymás közötti hatására és az egymástól való átvételekre is, nem mellőzi a keresztyénségnél sem ezeknek a kellő helyen való megemlítését, amivel persze szintén bizonyságot tesz annak is a relatív volta felől.


– Zoványi Jenő: A világ vallásai. Nyugat, 1927. 23. sz.

S ez a mozzanat, bármennyire is hangoztassa Garaczi műve a szövegben fellelhető, a szöveg által meghatározott szubjektum nem-létét, ellehetetlenülését (akár nyíltan, deklarálva, akár a rafináltabb nyelvhasználat tarka-barka köntösében), – mégiscsak egyedi, különös és érzéki jelenség: karakteres szubjektum-szerűség tehát.


– Bazsányi Sándor: Mi is az, hogy humor? Alföld, 1996. 5. sz.
156

Mondom: értem, mit akartál,

H.Z. · 2014. Szep. 16. (K), 08.40
Mondom: értem, mit akartál, csak érzésem szerint a létige nem stimmelt :)
Legalábbis XX., XXI. századi nyelvben nem jellemző. És ezt az idézeteid sem cáfolták.
159

Kötőmód?

Hidvégi Gábor · 2014. Szep. 16. (K), 11.54
Valószínűleg más lehet, mert a Wikipédia ezt írja: A kötőmód
Elnevezését onnan kapta, hogy általában az alárendelő összetett mondatok mellékmondataiban állva olyan cselekvést vagy történést fejez ki, amely a főmondat tartalmához vagy a mondatrészek közötti kapcsolat által kifejezett körülményhez kötődve – annak alávetve – nem tényszerű (bizonytalan, kétséges, lehetséges, valószínű, feltételezett, vélt, megkívánt stb.) jelleget ölt.
A magyarban alaktanilag nem létezik a kötőmód

Mindazonáltal lehet, hogy helyes, ahogy írtad, de egyelőre még gyanús.
160

Ellentmondás?

Endyl · 2014. Szep. 16. (K), 12.20
Ebben mi mond ellent annak, hogy ez kötőmód lehetne? Idézem tovább az általad idézettet (kiemelés tőlem):

A magyarban alaktanilag nem létezik a kötőmód (vagyis nincs az igének külön alakja erre): funkcióját többnyire a felszólító mód, valamint esetenként a feltételes mód látja el. Alaktanilag egybeesik a felszólítómóddal, mondattanilag viszont különbség figyelhető meg:
161

Kötőmód?

Hidvégi Gábor · 2014. Szep. 16. (K), 12.24
Megdöbbentő, hogy negyven év szocializmus után még mindig van, aki pont ugyanazokat a gondolatokat hangoztassa.
Ebben a mondatban én sem felszólítást, sem pedig feltételes módot nem látok.
162

hangoztassa

Poetro · 2014. Szep. 16. (K), 12.35
A hangoztassa a hangoztatja felszólító módja, hasonlóan az hangoztatsz, hagoztass, csak előbbi tárgyas eset.
163

Igaz

Hidvégi Gábor · 2014. Szep. 16. (K), 13.03
Ez igaz, csak a fenti mondat az kijelentő, nem pedig felszólító. Tehát máshol lehet a kutya elásva.
164

Nyilván nem felszólító

Endyl · 2014. Szep. 16. (K), 13.13
Nyilván nem felszólító mondat; csak alakilag egyezik meg a felszólító móddal, nem eredményez felszólító mondatot a használata (és nem is kell, hogy azt eredményezzen, mivel más módot jelöl).
166

Kötőmód?

Hidvégi Gábor · 2014. Szep. 16. (K), 16.22
Ez oké, de kijelentő mondatban nem használjuk az ige felszólító alakját. A hivatkozott wikipédia leírásban egyértelművé teszik, hogy ha kötőmódot használunk vagy fordítunk, abból felszólító vagy feltételes módú mondat lesz.
168

Igen

Endyl · 2014. Szep. 16. (K), 17.16
Hol írják azt, hogy a kötőmód felszólító vagy feltételes mondatot eredményezne?

Annyit írnak, hogy az ige melyik módját (tehát alakját) kell használni bizonyos esetekben. Mivel nincsenek saját alakjai a különböző kötőmódi eseteknek (mert egybeesnek jobbára a felszólító és feltételes móddal) ezért ezeken a nevükön említik a használandó alakot.

A függő beszéd második példamondatában is felszólító módban szerepel az ige, mégis kijelentő a mondat.

Idézet a Nyelv és Tudományból (kiemelések tőlem):
Először azt érdemes megvizsgálnunk, hogy milyen esetekben fordul elő a felszólító módú igealakoknak ez a meglepő, nem felszólító értelmű használata. Hamar megállapíthatjuk, hogy ez a jelenség tipikusan alárendelt tagmondatokban fordul elő, és nagyban függ a főmondat állítmányától, azaz bizonyos főmondati állítmányok előírhatják, hogy az alárendelt mondatban nem lehet kijelentő módú igét használni, hanem kötelező az igének ezt a bizonyos, felszólító módú alakját, akkor is, ha a mondat semmiféle felszólítást nem fejez ki.

Mindezek alapján jogosan merül fel a kérdés, hogy ha egyszer ezeknek az igealakoknak kétféle használatuk van, miért épp felszólító módúaknak hívjuk őket. Láthattuk, hogy a kötőmódot nem tudjuk a felszólítás egyik alesetének tekinteni; fordítva azonban elmondhatjuk, hogy a felszólítások is olyan eseményekre, tevékenységekre stb. vonatkoznak, amelyekről nem tudjuk, hogy valóban bekövetkeznek-e, vagy sem, csupán azt tudjuk, hogy valaki szeretné ezeket valaki mással elvégeztetni. Sokan éppen ezért amellett érvelnek, hogy hívjuk ezeket az igealakokat kötőmódúaknak (vagy esetleg kötő-felszólító módúaknak), amelyek a kötőmódú tagmondatokon kívül felszólításokban is előfordulnak.
169

Kötőmód?

Hidvégi Gábor · 2014. Szep. 16. (K), 19.38
Oké, már csak azt mondd meg nekem, hogy a fenti mondat mitől kötőmódú? Idézet az általad linkelt oldalról:
Vegyük észre, hogy ezeknek az állítmányoknak van egy fontos közös tulajdonságuk: olyan alárendelt tagmondattal állnak, amelyről (legalábbis a főmondat által jelölt időpontban) nem tudjuk, hogy igaz-e, vagy hamis. Nem is tudhatjuk, hiszen a főmondathoz képest egy későbbi időpontra utalnak, vagy legalábbis arra, hogy az adott esemény nem valószínű, hogy egyáltalán bekövetkezik.
Az Ádám által írt mondatban a mellékmondat eléggé konkrét.
170

Igen

Endyl · 2014. Szep. 17. (Sze), 11.14
Megdöbbentő, hogy a témáról ennyit olvasva még mindig van, aki ne lássa be, hogy a problémásnak vélt mondatban helyes a kötőmód használata.

Folytatom az idézést a nyestről az első idézetemnél (más kiemeléssel):
Először azt érdemes megvizsgálnunk, hogy milyen esetekben fordul elő a felszólító módú igealakoknak ez a meglepő, nem felszólító értelmű használata. Hamar megállapíthatjuk, hogy ez a jelenség tipikusan alárendelt tagmondatokban fordul elő, és nagyban függ a főmondat állítmányától, azaz bizonyos főmondati állítmányok előírhatják, hogy az alárendelt mondatban nem lehet kijelentő módú igét használni, hanem kötelező az igének ezt a bizonyos, felszólító módú alakját, akkor is, ha a mondat semmiféle felszólítást nem fejez ki. Ez igaz például a következő állítmánycsoportok esetén:
  1. Értékelés: fontos, hasztalan, szükséges, lehetetlen
  2. Távoli lehetőség: nem tudja elhinni, nem valószínű, kizártnak tartja
  3. Engedélyezés: megenged, lehetővé tesz, joga van
  4. Tiltás: megtilt, akadályoz
  5. Hajlandóság: igyekszik, fél, visszariad
  6. Vágy: vágyakozik, ácsingózik, szomjazik stb.


A megdöbbentő szerintem probléma nélkül beleillik az értékelő csoportba (olyan szinten biztos, hogy megengedje a kötőmódot, ha nem is követeli meg).

De a bizonytalanság is fellelhető benne a beszélő szempontjából. Egy másik cikkből:
Akkor használunk kijelentő módot, ha egy szereplő (az alany által jelölt személy, vagy a beszélő) elkötelezett az alárendelt mondatban megfogalmazott esemény megtörténte mellett, azaz olyan eseményről vagy tényállásról mond valamit, ami az ő legjobb tudása szerint biztosan megtörtént, vagy fennáll, míg a kötőmód esetében ezt nem mondhatjuk el.

A kérdéses mondatban a bizonytalanság a tényállás beszélő szerinti valószinűtlenségéből fakadhat (ha egyáltalán szükséges ez; bár ez a bizonytalanság dolog szerintem inkább csak iránymutató a kötőmód felismeréséhez - a cikk jellegéből fakadóan).

Illetve itt van még egy írás arról, hogy a kötőmódú tagmondatos mondatnak nem kell szükségszerűen sem felszólítónak, sem bizonytalannak lennie.
171

Köszönöm.

Hidvégi Gábor · 2014. Szep. 17. (Sze), 12.56
Köszönöm.

Hogy stílusos legyek: örömömre szolgál, hogy vannak, akik elsőre átlássák a dolgokat.
172

Nem kötőmód.

Hidvégi Gábor · 2014. Szep. 18. (Cs), 13.31
Nem győztél meg a bizonytalanság szemszögéből. Egyrészt az idézett cikked nem magyar nyelvre vonatkozik, másrészt ismét:
ezeknek az állítmányoknak van egy fontos közös tulajdonságuk: olyan alárendelt tagmondattal állnak, amelyről (legalábbis a főmondat által jelölt időpontban) nem tudjuk, hogy igaz-e, vagy hamis
Az Ádám által írt mondat alárendelt mondatrésze így hangzik:
van, aki pont ugyanazokat a gondolatokat hangoztassa
Norbi definite ezeket a gondolatokat hangoztatta, nincs semmiféle bizonytalanság. Ha valami van, az biztos valami.

Cserébe H.Z. kollegának igaza van abban, hogy ha Ádám úgy fogalmazott volna, hogy "Megdöbbentő, hogy negyven év szocializmus után még mindig legyen, aki pont ugyanazokat a gondolatokat hangoztassa." Itt a "legyen" már nem konkrét, mint a "van", mert benne van, hogy nincs senki (aki azokat a mondatokat hangoztatta volna).
147

A böngészők között azért

Hidvégi Gábor · 2014. Szep. 15. (H), 21.45
A böngészők között azért vannak különbségek, és ezt már múltkor megbeszéltük, mert maga a "szabvány" ezt megengedi. A CSS ajánlása tele van homályos megfogalmazásokkal, ráhagyásokkal, ez okozza a gondot. Ha ezek nem lennének, akkor rövid időn belül egy renderer maradna.

Ha már politikáról van szó, a szabványkészítés maga is aktív politikai terep, a nagy cégek képviselői a saját (céges) érdekeiket próbálják meg érvényesíteni, egymást fúrják. Kiváló példa erre a Microsoft-féle pointer events, amiben egyesíteni szerették volna az egér és az érintőképernyős vezérlés eseménykezelését, ami jelentősen leegyszerűsítette volna a fejlesztők munkáját, de ezt a Google nemrég megfúrta, és már nem támogatják.
151

A CSS ajánlása tele van

Joó Ádám · 2014. Szep. 16. (K), 00.32
A CSS ajánlása tele van homályos megfogalmazásokkal, ráhagyásokkal, ez okozza a gondot. Ha ezek nem lennének, akkor rövid időn belül egy renderer maradna.


Bocs, Gábor, de mégis hogyan jutsz ilyen következtetésekre? Úgy gondolod, hogy az Internet Explorer, a Firefox, a Safari és a Chrome/Opera (nemrég a perjel még eggyel odébb volt) azért használ különböző renderert, mert úgy gondolják, hogy más a helyes default font-size?

És ezek mind konvencionális böngészők, amik így vagy úgy, de C-ben íródnak. Mi van, ha valaki más nyelvű környezetben dolgozik? Mi van ha egy beágyazott rendszerről beszélünk?

A szabványosítás pedig természetesen politika, erről a magyar szabványügyi testületben az elmúlt években szerzett tapasztalaim alapján kellően gyomorforgató tapasztalataim vannak.
158

Ha a szabvány minden esetben

Hidvégi Gábor · 2014. Szep. 16. (K), 08.54
Ha a szabvány minden esetben pontosan definiálna, akkor a renderelés pixelpontosan megegyezne mindenhol, és legfeljebb sebességben lenne eltérés. A böngészőmotor egy elég összetett dolog, sok munkával jár, és innentől kezdve nem lenne értelme időt és pénzt rászánni még ennyi cégnek sem.

Jelenleg egy dolognak köszönhetjük a különböző böngészőmotorok létezését: a kis keresődobozénak, mivel közvetve ezen keresztül jutnak pénzhez a fejlesztők.
125

minden, azaz minden eszközön,

Poetro · 2014. Szep. 15. (H), 19.02
minden, azaz minden eszközön, platformon egyformán jelenne meg a site. Nem kellene tesztelni millió helyen, mert az egyetlen közös engine miatt borítékolt, hogy bárhol ugyanazt látom.

Ugye az eszközöknek különböznek a képességei, ezért nem láthatom ugyanolyannak a kimenentet. Különbözik a képernyő mérete, felbontása (valós és virtuális), színek száma (16 szinű e-Ink, 48-bites professzionális kijelző). Ezen kívül különbözik a beviteli forma (érintés, egér, billentyűzet, stylus, távirányító, gamepad stb.), ami szintén befolyásolhatja, hogyan kell megjeleníteni a tartalmat.

Mert hiába nézem én Full HD kijelzőn a weboldalt, ha az eszközöm egy mobiltelefon, egy PC monitora, egy tablet, egy TV, mindehol másként illik megközelíteni a kérdést, mert máshogy fogyasztom a tartalmat.
126

Itt az lenne a lényeg, hogy

Max Logan · 2014. Szep. 15. (H), 19.16
Itt az lenne a lényeg, hogy pontosan ugyanazok az algoritmusok futnak le egy telefon, egy tablet, egy Windows-os, egy Mac-es, egy Linux-os böngészőben. Nincsen varia, hogy IE így futtatja a JS kódot, a Linux-os Firefox meg úgy. Azaz minden maradna a régiben, és a külső libek, legyen szó JS-ről, vagy CSS-ről, beleépülnének a motorba.
139

XHTML

Hidvégi Gábor · 2014. Szep. 15. (H), 21.04
Az XHTML-be bele volt kódolva a bukás. Addig még megyegetett a dolog, hogy szingli tag-ek végére rakjunk be egy / jelet, de ahhoz, hogy olyan dokumentumot hozhass létre, amiben az alap HTML tag-eknél több van – olyanok, amelyek jelentést is hordoznak az adott objektumról (pl. <telefon>) –, már saját DTD írását tette szükségessé, amihez nem adtak semmilyen komolyabb segítséget.

Már korábban írtam inf3rnonak, akkor fog bármi igazán szemantikus elterjedni, ha ugyanolyan faék egyszerűségű lesz, mint a HTML.
145

Addig még megyegetett a

Joó Ádám · 2014. Szep. 15. (H), 21.38
Addig még megyegetett a dolog, hogy szingli tag-ek végére rakjunk be egy / jelet


Nem, épp ez az, hogy nem ment.
102

Minél jobb eszközöket adsz a

bamegakapa · 2014. Szep. 10. (Sze), 15.54
Minél jobb eszközöket adsz a fejlesztők kezébe, annál olcsóbban, gyorsabban tudnak jobb, szebb, gyorsabb termékeket készíteni a felhasználóknak. Túl sokszor le lett futva ez a HTML5-ös hülyeség ahhoz, hogy most kedvem legyen mélyebben belemenni.

Milyen kutatás támasztja alá, hogy a felhasználóknak mindennél fontosabb a hatékony keresés?

Ami meg a Flasht (Silverlight, stb.) illeti, a puszta létezése és népszerűsége is azt mutatta, hogy igen komoly problémák vannak. Ha a web komolyan akarta venni magát, lépni kellett valamit.
104

Ok, tegyük félre a

Hidvégi Gábor · 2014. Szep. 10. (Sze), 15.59
Ok, tegyük félre a HTML5-öt.

Milyen kutatás támasztja alá, hogy a felhasználóknak mindennél fontosabb a hatékony keresés?
Egy ötös skálán ezt a kérdést mennyire szántad komolynak? 1: teljesen komolytalan, 5: nagyon komoly.
107

Tegyük fel, hogy komoly. Az

bamegakapa · 2014. Szep. 10. (Sze), 16.18
Tegyük fel, hogy komoly. Az eddig lefektetett elvek alapján az számít, hogy a 92%, aki azt se tudja, mi az a böngésző, jól érezze magát. Az ő véleményükre lennék kíváncsi. Használják ők az internetet vajon fészbúkozáson, hírolvasáson és pornónézésen kívül valamire? Valóban a keresést tartják a legégetőbb problémának? Ha nem, hányadik helyre tennék? Tudják-e, egyáltalán mi az a "keresés"?

Hidvégi Gábor véleménye itt épp annyira nem lényeges, mint bamegakapáé. Mi valószínűleg mindketten szeretnénk hatékonyabb keresést.
109

Tegyük fel, hogy komolyEz

Hidvégi Gábor · 2014. Szep. 10. (Sze), 16.38
Tegyük fel, hogy komoly
Ez aztán a határozottság, "Csak nehogy olyat írjak, amit utána fel tudnak ellenem használni".

Ha megnézed ezt a statisztikát, akkor láthatod, milyen mértékben nő a website-ok és az internet felhasználóinak száma, de a legfontosabb oszlop a táblázatban a felhasználók száma per website: 2013-ra oldalanként csak 4 látogató jut. Ez azt jelenti, hogy az interneten lévő mérhetetlen (és egyre inkább növekvő tömegű) információ egyre kevesebbekhez jut el.

Következmények:
1, a site-ok tulajdonosainak egyre többet kell költeniük marketingre
2, cserébe a site-ok fejlesztésére arányosan kevesebbet tudnak költeni, azaz idővel csökkenni fog a te fizetésed is

Ez az ára a kényelmes fejlesztésnek, amit neked kell kicsengetned. Ezért kellett volna a keresés hatékonyságát növelni, hogy az általad létrehozott website-on lévő információk eljuthassanak a célcsoporthoz.
110

Ez engem nem elégít ki

bamegakapa · 2014. Szep. 10. (Sze), 16.59
Ez engem nem elégít ki túlzottan. Hol látom itt, hogy a felhasználóknak a keresés hatékonysága a legfontosabb?

Még fontosabb: egyáltalán képesek lennének-e az amúgy is techanalfabéta, de mesterségesen még tovább butított felhasználók (a 92%, akik elől mindent gondosan elrejtünk, ami bonyolultabb egy faéknél) keresni? Képesek lennének-e bármilyen, gép által értelmezhető formára hozni az agyukban feltoluló, maguk számára is alig értelmezhető igényeket és gondolatfoszlányokat? Lehet készíteni egy rendszert, amivel a 8% (egyszerűség kedvéért használjuk ezeket a számokat), akik jelenleg is nagyrészt megtalálják, amit keresnek, gyorsabban és hatékonyabban jutnak információhoz, de ugyanitt lennénk, a 8%-nak dolgoznánk (ami ugye, mint megbeszéltük, pazarlás). A probléma az, hogy a 92% jellemzően kérdéseket sem képes feltenni, ami sokkal fontosabb képesség, mint gondolnánk.
111

Abból, hogy az embereknek

Hidvégi Gábor · 2014. Szep. 10. (Sze), 17.24
Abból, hogy az embereknek csak 8%-a tudja, mi az a böngésző, nem következik, hogy nem tudják, mit akarnak.

Vegyük az egyszerű dolgokat, például lakás. Mivel nem szöveges információról van szó (tudom, hogy mekkorát szeretnék venni, mennyi pénzem van rá, és hogy helyileg hol legyen), a google és a többi szöveges kereső azonnal elbukik. Ilyenkor nincs más választásom, végig kell nyálaznom n darab ingatlanos site-ot, ha meg szeretném találni a számomra megfelelőt. Ahogy az internet nő, egyre több időt kell eltöltenem a keresgéléssel.

Könnyebben megfogható termékeknél és szolgáltatásoknál egyre népszerűbbek a gyűjtőoldalak, mint például az árukereső.hu, de van ilyen biztosításokra szakosodott site is. Viszont ezeket nem feltétlenül találja meg minden oldaltulajdonos, vagy esetleg nincs is pénze a havidíjra. Innentől kezdve az idő előrehaladtával egyre kevesebben fogják megtalálni az oldalát.

Nehezebben megfogható dolgoknál, mint például útleírások blogokban, ahol még ilyen gyűjtőoldalak sem nagyon léteznek, még rosszabb a helyzet.

Ebből következik, hogy minél több időt töltünk magunkkal (a kényelmes programozás fejlesztésével, szabványosítgatással), annál több pénzt veszünk ki a megrendelőink és a magunk zsebéből, és annál inkább pazaroljuk az internet használóinak idejét.
116

Megint arról a részről

bamegakapa · 2014. Szep. 11. (Cs), 12.24
Megint arról a részről beszélsz, amiben egyetértünk. Ez szerintem is remek lenne. Azt nem írom alá, hogy a dühödt felhasználók ezt követelik tőlünk, de ennek én is örülnék.

Szerintem hagyjuk az egészet, csak millióegyedszer is leírjuk, ami már milliószor leiratott itt, körbe-körbe rohangálva.
86

Ez célközönség függő is

inf · 2014. Szep. 10. (Sze), 13.57
Ez célközönség függő is lehet. Pl ha cégnek fejlesztesz, be lehet tanítani a felhasználókat a szoftvered használatára, illetve további ötleteket kérni, hogy hogyan lenne jobb a rendszer szerintük.
85

ettől függetlenül arra még

inf · 2014. Szep. 10. (Sze), 13.54
ettől függetlenül arra még senki sem tett komolyabb erőfeszítést a HTML-lel kapcsolatban, hogy az interneten található mérhetetlenül sok információban könnyebben lehessen keresni a látogatóknak


El vagy tévedve ezzel kapcsolatban.
Csak néhány a létező megoldások közül.
88

Ha már URL a téma...

Max Logan · 2014. Szep. 10. (Sze), 14.28
...akkor nézzünk egy életszerű példát, amit én mondjuk nem kicsit, hanem nagyon rossz megközelítésnek tartok.

Adott két, találomra kiválasztott URL:
http://www.portfolio.hu/vallalatok/norbi_a_hu_az_komoly_kategoriaba_akartam_kerulni.203457.html
http://www.edigital.hu/Kartyaolvaso/Kingston_MicroSD_Reader_G2_kartyaolvaso-p405043.html

Mindkettő esetén látszik, hogy gyúrnak a szépnek ható URL-re, de ott egy kód is. A „legszebb” a dologban, hogy ha átírom a kód mellett lévő szöveget, mindkét URL működőképes marad, az ID miatt ugyanazt a tartalmat kapom (nem pedig 404-et).

Ha a kereső megeszi a szép(nek ható) URL-eket, és valamilyen formában ez alapján súlyozza a találati listát, akkor ezzel a megoldással kb. tökönlőtték magukat ezek a site-ok...
89

Redirect

Poetro · 2014. Szep. 10. (Sze), 14.43
Ami hasznos lehetne a fenti esetben, az egy permanens redirect a permalink-re. Azaz ha át is írod az URL-t, de az azonosítót meghagyod, akkor is irányítson vissza téged a kanonikus URL-re.
90

ezzel a megoldással

Hidvégi Gábor · 2014. Szep. 10. (Sze), 14.58
ezzel a megoldással kb. tökönlőtték magukat ezek a site-ok
Miért? Ezt nem értem. Csak akkor okozhat problémát, ha site-on belül ugyanarra a termékre két különböző linket gyártanak, de ezt valószínűleg nem fogják elkövetni.
94

A probléma az, hogy ezzel a

Max Logan · 2014. Szep. 10. (Sze), 15.28
A probléma az, hogy ezzel a megoldással a rafinált konkurensek lejáratós linképítést tudnak elkövetni, a lehetőséget pedig maga a site biztosította.
93

Nem értem, hogy miért kellene

inf · 2014. Szep. 10. (Sze), 15.09
Nem értem, hogy miért kellene 404-et adniuk. Tetszőleges számú URL tartozhat ugyanahhoz a webes erőforráshoz...

A tökönlövés részét nem igazán értem, kifejtenéd?
95

Lásd 94-es hozzászólásom.

Max Logan · 2014. Szep. 10. (Sze), 15.31
Nem értem, hogy miért kellene 404-et adniuk. Tetszőleges számú URL tartozhat ugyanahhoz a webes erőforráshoz...
Yes, de ez a keresők szemszögépéből duplikáció.

A másik kérdésben pedig lásd 94-es hozzászólásom.
96

Nem az, ha kiteszel egy

inf · 2014. Szep. 10. (Sze), 15.33
Nem az, ha kiteszel egy canonical link relation-t, ami az eredeti nevet tartalmazza... Egyébként sem valószínű, hogy bárki ilyesmivel töltené az idejét, hogy lejárató linkeket gyártson.
97

főleg nem egy konkurens

Poetro · 2014. Szep. 10. (Sze), 15.35
főleg nem egy konkurens weboldalára, amivel még esetleg plusz forgalmat is generál neki.
105

Vegyük úgy, hogy nem

Max Logan · 2014. Szep. 10. (Sze), 16.03
Vegyük úgy, hogy nem konkurens, és vegyük úgy, hogy olyan forgalmat generál mondjuk a site-nak, amit nem bír el, és/vagy irreleváns látogatók érkeznek, stb, stb.

A lényeg, hogy ez szerintem logikai hiba, system error, én biztosan nem engedném. Ha másnak nem gond, azt persze elfogadom.
98

Egyébként sem valószínű, hogy

Max Logan · 2014. Szep. 10. (Sze), 15.40
Egyébként sem valószínű, hogy bárki ilyesmivel töltené az idejét, hogy lejárató linkeket gyártson.
Vannak, akik nem válogatnak az eszközökben...

De ha csak az elvi részét nézzük, akkor is minimum redirect-elni kellene az eredeti és egyetlen URL-re, mert az én nézőpontom szerint domain-en belül egy adott tartalom csak egyetlen címen legyen elérhető.
108

Ahogy már említve lett,

bamegakapa · 2014. Szep. 10. (Sze), 16.26
Ahogy már említve lett, canonical url-t meg kell adni, és akkor a guglit nem fogja zavarni. Gyakorlatilag jelzed, hogy melyik az elsődleges URL, amin ugyanez a tartalom elérhető. Bizonyos esetekben nem is biztos, hogy elkerülhető, hogy több URL-en ugyanaz a tartalom jelenjen meg.