WebStandarts

bubu - lab, izteicos neprecīzi - nepareizs ir nevis AJAX pēc būtības tur, bet drīzāk gan user interface. Pat ja notiek visādas AJAX un JavaScript funkcijas, es tomēr pieturos pie skaidra principa: "Vizuālā lietotāja interfeisā jābūt ir skaidri redzamai funkcijai, tās hierarhijai, lomai un visuālai kontrolei." Keybord shortcut nav vizuālā kontrole - tas var būt alternatīvs kontroles paņēmiens, bet kopš kura laika man, kā lietotājam, ir jāsaprot, ka ENTER nozīmē - Save vai OK. Man ir pele, es braukāju ar to un man ar to jābūt visam izdarāmam (izņemot typing). Atbalstu "keyboard shortcuts" bet tikai kā alternatīvās kontroles jau esošajām vizuālajām.

Es teiktu, pat krīzes laikā tā ir nožēlojama summa par ko strādāt. Ko tas maina, ka ir krīze? Visi ir nabadzīgi, bet - cenas veikalos un par pakalpojumiem ir mainījušās? Nē, tas ir pat ir kļuvušas dārgākas. Tāpēc uzskatu, ka 60 Ls ir nožēlojama summa, par ko taisīt praktiski jebkādu webprojektu. Tad jau rodas jautājums - a kāpēc tad nedarīt to par kartupeļu maisu vai varbūt vispār par brīvu? Nu ja krīze, tad krīze, naudas nav nevienam! :D Nekam neder tāda attieksme. Un tā aizbildināšanas ar "krīze, krīze" visur jau kļūst kaitinoša. Tik pat labi, man ir tiesības aiziet uz veikalu un pateikt - par šito sulas paku es nemaksāšu latu, es maksāšu tikai 50 santīmus, nu krīze kā nekā... Lai gan visa tā valsts attieksme pret šo visu liek man pamatīgi apsvērt, kā lai no šejienes pēc iespējas ātrāk tiktu prom...

bubu, es varu paskatīties, kas notiek citos laukos, paklikšķināt citur un tikai tad nospiezt ok. Es tā mēdzu darīt arī. Jābūt pogai OK - pie tā nu es palikšu, nepārliecināsiet par to, ka tikai ar ENTER nospiešanu ir līdzēts. ;) bubu - user interface - cieši saistīts ar AJAX, ja runājam par web aplikācijām. Kas tehnoloģiski veido User Interface web aplikācijā? Manuprāt: 1) presentation layeris (css); 2) content (html tagi un viss, kas atrodas tajos); 3) behaviour - te nu ir gan javasript, gan AJAX, jo tā ir mijiedarība būtībā uz lietotāja darbībām.

Uz manu jautājumu, kāds esot šī projekta budžets, Rihijs atbildēja: Protams, ka runa ir par latiem, ko gan citu. ;) Jā, varens budžets! :)

Pilnīgi muļķīgi, ka ar ENTER nospiešanu tiek saprasts, ka es esmu pabeidzis ierakstu. Jābūt pogai OK.

Atbildu uz jautājumu un arī paskaidroju: AJAX jāizmanto, lai: 1) padarītu darbu ar web aplikāciju ērtāku; 2) atvieglotu trafiku - pieprasītās informācijas apjomu, nesūtot vairākas reizes lietas, kas būtībā nemainās. Tas ļautu paplašināt web aplikācijas funkcionalitāti, neciešot tās ātrdarbībai - vismaz kas attiecas uz ceļu serveris->klients un atpakaļ. Tātad, web aplikācija kļūst "rich" un no vienkāršām html lapām tā sāk pārvērsties par universālu aplikāciju, ko spēj izpildīt populārākie un modernākie pārlūki. Tavā menedžeri AJAX ir izmantots nevietā - ar to es domāju, atsevišķas funkcionalitātes ir veiktas ar AJAX, kas par brīnumu, nevis darbu atvieglo, bet pat padara to neērtu. Kāpēc nav pogu? Tās ir atceltas? Tev ir jāpadomā par usability. AJAX protams, jāizmanto, nenoliedzu, bet māksla ir to arī izmantot pareizi. ;) Es pat teiktu - efektīvi un optimāli izmantot AJAX - tā ir meistarība. Mans uzskats, ka vizuālā aplikācija ir jāizmanto vai nu pogas vai drag&drop vai arī kombinēti. Keybord Shortcuti paši par sevi vien nav risinājums web aplikācijā.

Lūdzu nevajag taisīt bezjēdzīgas QUOTEs Pagaidām arī neko labu nevaru pateikt par to menedžeri - 1) tur praktiski nekā nav - darba nosaukums un saglabāt?. 2) galīgi nevietā izmantots AJAX.

Tieši tā. Profesionāla pieeja - katrs cilvēks veic savu darbu un katra darba stunda ir apmaksāta. Vai tas būtu klientu menedžeris (kurus nezin kāpēc Latvijā dēvē par projektu vadītājiem), vai programmētāju grupas vadītājs - vecākais programmētājs (kuri nez kāpēc Latvijā mēdz būt tie paši klientu menedžeri), jebkuram cilvēkam ir savas darba stundas, pēc kurām piestādīt rēķinu klientam. It kā objektīvi darba stundas likme sevī varētu iekļaut: 1) tiešo darbinieka algu; 2) apgrozāmo līdzekļu (dators, telpas) nolietojuma daļu, kas aprēķināta uz vienu darba stundu par pamatu ņemot attiecīgās darba vietas daļu un 40 h darba nedēļu, kas varētu būt kaut cik ievērojams vienīgi pateicoties telpu īrēm utml. 3) citas izmaksas (neesmu grāmatvedis, nepateikšu); 4) uzņēmuma peļņu; 5) nelielu rezervīti (ja izmaksas var mainīties) - izlēdz palikšanu uz 0 peļņu vai mīnusos; 6) nodokļi. Un tas arī visu iekļauj. Stundu likmes mēdz būt fiksētas, tāpēc uzņēmuma peļņa ir mainīga, jo izmaksas ne vienmēr ir tādas kā aprēķinātas iepriekš, savukārt klientam tu nevari teikt - šodien mums būs 25 Ls stundas likme, bet rīt 30 Ls. Tāpēc arī šīs likmes mēdz būt palielas, jo iekļauj to rezerves daļu, ja nu gadījumā izmaksas izrādās pārāk lielas (pārāk dārgs programmeris bij nepieciešams vai arī par daudz notērēja benzīnā, mītingos). Klientam būs skaidrs, par ko viņš maksā, uzņēmumam būs peļņa praktiski vienmēr. Pie tam, ja kāds no darbiniekiem uz savu stundas likmi ir ietaupījis (teiksim, programmeris uzprogrammējis ātrāk nekā cerēts), tad tur arī rodas rezerve, ja kāds cits darbinieks savas stundas ir pārtērējis. Klientam ta vairāk vai mazāk no tā neprasīsi - parasti ar klientu par cenām vienojas iepriekš. Lai gan var vienoties arī, ka maksāts tiek pēc tam saskaņā ar reāli patērētām stundām - nu tas jau ir paradīzes gadījums.

Wiki būtu pats elementārākais, vienkāršākais un universālākais variants, savukārt, bieži vien vajag konkrētāku un specializētāku sistēmu, kur ir lietotāji ar savām tiesībām. Piemēram, issue trackeris JIRA - šis risinājums principā der lieliem projektiem.

Es teiktu, ka vismaz 200 Ls (bez jebkādām kvalitātes prasībām), bet vismaz 400 Ls par kvalitatīvu produktu.

Tas iedalījums tur ir dīvains. Ko nozīmē "Copywriting", ko nozīmē "Miscellaneous"? Pie tam es neizprotu, kāpēc tik daudz pozīcijas veltītas dizainam, ja par vizuālo dizainu varētu runāt tā - idejas izklāsts (ietilpst iekš Client Meetings), skices un apstiprinātās skices gatavais dizains - viss. Ja runājam par Information Architecture - tad tur var ietilpt gan ļoti daudz un sarežģītas lietas, gan arī viens teikums - "Izmantosim mūsu frameworku MVC stilā". Tā varētu būt nosacīti Information Architecture - konveijera lapām to nevajadzētu tik ļoti uzsvērt, jo parasti jau šī arhitektūra ir gatava, nepieciešams tikai melnais darbs - programmēšanu izdarīt. Viss tas iedalījums ir tāds vidusceļš - starp lielu projektu un nelielu webu. Ne šis ne tas. Mazajiem webiem nevajag vismaz Information Architecture, Design Revisions (skaitīsim laiku, pa kuru klients skata skices?), Photo Art Direction (šo darbu parasti veic dizaineri vai klients pats ar saviem resursiem pēc izstrādes jau) - tikpat labi mēs varētu tur ieskaitīt vēl servera uzturēšanu, hostingu īri un sazin vēl ko, bet cik saprotams, runa iet par web-development. Kā arī dziļdomīgais Miscellaneous - nav jēga izdalīt sadaļas, kas nav skaidras. Ja zem "dažādi" ir paredzēts tas, ka viens darbinieks ir saslimis un uzņēmējam nācās apmaksāt to, ka viņš neko nespēja darīt, tad tā ir uzņēmēja problēma un neprofesionalitāte, ja viņš to apzināti ieliek zem "dažādi". Ja es būtu klients, es nekad nemaksātu par kaut kādu sadaļu, kas saucas "Dažādi". Savukārt, nozīmīgiem projektiem var savajadzēties vēl sadaļas. Bet ir kaut kādas cietās starta sadaļas lieliem projektiem, bez kurām nekādi (izlaidīsim visādus client meeting and "pļāpīng pie kofē and tāfeling skečes"): 1) System & Information Architecture 2) Technology Research & Analysis šiem diviem pirmajiem vajadzētu radīt arī tā saucamo tehnisko specifikāciju - tur jābūt iekšā arī kvalitātes prasībām un iespējamo nākotnes izmaiņu paredzēšanai. While (still in development) { 3) Developing 4) Testing & Debugging } 5) projekta palaišana produkcijā un visi ar to saistītie sīkumi (kurus būtu jāuzskaita pa apakšpunktiem) Bet tie ir tikai veicamie uzdevumi un procesi. Ja runājam par darba stundām un samaksām, tas ir kas pavisam cits - katra cilvēka stundas likme x cilvēka patērētās (vai prognozētās) darba stundas pie konkrētā projekta. Viss.

Par velti nekad nevajag taisīt lapas (izņemot, ja tie ir tik tuvi paziņas, ka tur ir savas intereses). Par velti strādāt - nu tas ir velti darīts. Otra lieta ir tā, ka šitādi kadri čakarē tirgu pamatīgi. Jau tā apstākļi ir drūmi, vēl atrodas vergi - pazemo ne tikai paši sevi, bet arī čakarē citiem dzīvi, jo atradīsies tagad tādi, kas iedomāsies, ka darbs un zināšanas neko nemaksā... P.S. Izdomā ideju un taisi pats savu projektu - tas būtu DAUDZ LABĀK, nekā taisīt kādam citam projektu par velti. Hostings neko dārgi nemaksā, bet toties projekts piederēs tev.

Laiks izstrādāt speciālo XML hibrīdu kādu - subvalodu, kas paredzēta būtu tikai priekš mailto: protokola vai kā tur sanāk - īsāk sakot - tikai priekš e-pastiem ar iespēju pievienot speciālu css (var ar apgraizītām fīčām). Līdzīgi kā WML arī tam vajadzētu būt ar nepieciešamo minimumu, HTML tomēr ir paredzēts web lapām, kuras var būt arī ļoti "rich". E-pastā nevajadzētu atļaut sūtīt, piemēram, video vai flash (kā inline elementus).

Principā piekrītu. E-pasts nav web lapa vai buklets, tas ir paredzēts sarakstei un informācijas sniegšanai teksta veidā. HTML meilu atbalstu vienīgi tad, ja informāciju nepieciešams sniegt tabulas formā. Sorry, ja vajag bildes, vajag linkus, tak ielieciet linku tai e-pastā, nu nav tas e-pasts paredzēts tādiem štruntiem - bilžu galerijas, vizuālas reklāmas un vēl sazin kas. Spams vispār nav atbalstāms, arī nekādi reklāmas e-pasti, izņemot, ja esmu kaut kādā konkrētā saitā vai kādā vietā pats parakstījies, ka vēlos tos saņemt no attiecīgās kompānijas - nu pašsaprotami. Šeit es vēlos negatīvi izteikties par inbox.lv - diemžēl, ne tikai neprofesionālā programmēšana (e-pasts balstīts uz horde engini?), pretīgais stils un mūžīgā bremze dēļ pārslodzes ar reklāmām, bet arī tas, ka inbox pats man sūta savu sūdu sponsoru spamu. Kādā rakā? Lai mācās no gmail. Inbox.lv man jau vairs praktiski neviens nopietns e-pasts nav, tik surogātsūdi.

Parasti Outlook smuki bloķē bildītes vai firewall nelaiž tās cauri, kā nu kurā uzņēmumā un pret to nav iespējams cīnīties.