Mam taką sytuację projektuję stronę www która miała być zwykłą stroną tanio i szybko zrobioną.
Tymczasem klientka ciągle się czepia, że coś należało by przesunąć o 2 pixele w prawo lub w lewo, gdzieś tam zmienić odcień na inny, że gdzieś czcionka ma inny rozmiar (jak się wpatrzy to może o pixel mniejsza), lub na wszystkich przeglądarkach strona wygląda ok a na IE 7 oczywiście nie...
No i rozumiem można poprawiać ale jak nie było mowy o aż takiej dokładności (Cena tego nie uwzględniała) i nie było tego w specyfikacji to co zrobić z takim klientem bo się można zaj.. nad każdą pierdołą... ona musi dosłownie robić screeny i powiększać je bo różnic przesunięć o 1 pixel nie widać... wtf i co zrobić.
0
3
Przede wszystkim, trzeba mieć lepsze umowy. Zgodność z przeglądarkami MUSI być w specyfikacji wymagań! Podobnie jak to, jakie zmiany i odchyły z designem są tolerowane.
Co do stopnia pisma ("rozmiaru czcionki"), to 1px akurat robi różnicę, szczególnie przy mniejszych stopniach. Trzeba to poprawić. Ale już to, że tekst nie jest renderowany dokładnie tak przez przeglądarkę jak przez Photoshopa, tj. że litery w PS-ie mogą być grubsze, to norma i nie da się tego naprawić w żaden rozsądny sposób.
Z umowy trzeba się wywiązać. Jeśli witryna (lub jej część) spełnia warunki umowy, tj. jest "ukończona", a klient chce jeszcze jakichś zmian, należy powiedzieć klientowi, że będzie go to kosztowało dodatkowoo tyle i tyle zł. Z tym klientem nie wolno już więcej współpracować. Umowy, na przyszłość, trzeba poprawić.
To Ty, jako profesjonalista (czy na pewno nim jesteś?), odpowiadasz zarówno za projekt -- końcowy rezultat i samo prowadzenie projektu -- jak i za wybór klienta. Wkurzony, jeśli już, bądź na siebie.
0
co masz w umowie/specyfikacji? ma być zgodne co do piksela z layoutem z obrazków? jeśli te zmiany można zakwalifikować jako poprawki, to niestety klientka ma rację. jeśli była tylko ustna umowa, to też możesz mieć problem.
powinieneś pogadać z klientką i wytłumaczyć, że będziesz robić te zmiany, ale tylko za dodatkową kasę. i powinieneś być asertywny. bywają też sytuację, kiedy warto machnąć ręką na projekt i kasę, będziesz w plecy finansowo, ale w przeciwnym wypadku możesz się męczyć z takim upierdliwym klientem jeszcze długie miesiące. i nawet, jeśli nie zrobisz tak faktycznie, to warto takiego klienta poinformować o tym, że jesteś na to gotowy - klient też zainwestował ileś swojego czasu w ten projekt i nie będzie chciał go marnować.
0
W kwestii zgodności to strona wygląda na wszystkim identycznie a na IE7 i niżej są drobne różnice aż tak się nie rozdrabiałem (na IE 8 ok) następnym razem wezme chyba tabelkę z numerkami przeglądarek i każe zaznaczyć na liście. no nic jakoś się te poprawki hakami naniesie ale żeby przesuwać coś i robić odrębne style z powodu takich pierdół..:D no nic dzięki :)). Myślę że jakoś się ugadam bo przecież strona jest dobra na szczęście nowe wydania IE już tak nie straszą.
4
Ziom, ja rozumiem, że niektórzy klienci faktycznie są upierdliwi... ale wymaganie by strona wyglądała tak samo na wszystkich przeglądarkach jest 100% normalne i słuszne --' Za to branie się za webdeveloperkę, jak się nie umie tak ciąć, by i pod IE było ok to normalnie kiepski pomysł.
Współpracowałam już z kilkoma takimi, co mi twierdzili, że pod IE się inaczej nie da jak oddzielnym plikiem styli --' Bzdura, pewnie masz babole w htmlu/cssie i tyle.
5
@"pewnie masz babole w htmlu/cssie i tyle"
Raczej "pewnie masz za dobry html/css i nie uwzględniasz dziwactw innych przeglądarek".
3
Użycie zaawansowanych mechanizmów z HTML-a czy CSS wpływa korzystnie na semantykę, szybkość ładowania, elastyczność i koszt strony. Jeśli jednak użyjemy "zbyt wiele" tych dobrodziejstw, tj. nasz kod będzie "za dobry", i jednocześnie olejemy dziwactwa i braki słabszych przeglądarek (a olanie ich polepsza modyfikowalność, zmniejsza koszty testowania, integracji i tworzenia witryny), to wtedy pojawią się znaczne różnice w renderingu strony.
By rozstrzygnąć dyskusję w temacie: "Czy kod jest za dobry, czy za słaby dla IE7" prosiłabym @wkurzonego-designera o zaprezentowanie swojego kodu :]
4
@aurel:
To są dwie-trzy oddzielne rzeczy:
- Czy to, że kod nie działa w IE7 (tak jak w innych przeglądarkach) oznacza, że zawiera babole?
Odpowiedź: zdecydowanie nie. - Czy to, że kod nie działa w IE7 (tak jak w innych przeglądarkach) oznacza, że jest słaby?
Odpowiedź: niekoniecznie. Jest nieco mniej przenośny, ale ma lepsze inne atrybuty jakościowe: wydajność, modyfikowalność/łatwość w utrzymaniu, niższy koszt czasowy. A przy tym witryna wciąż może być w pełni dostępna. - Czy kod, który napisał @wkurzony-designer jest dobry?
Prawie na pewno nie jest. Prawie na pewno jest słaby. Zdecydowana większość kodu frontendowego jest słaba lub bardzo słaba.
BTW: zauważ, że przy zastosowaniu "fixów na gradient", które uznajesz za podstawę, tracimy część tych atrybutów jakościowych wymienionych w punkcie 2: kod staje się trudniejszy w modyfikacji i pisze się go dłużej. Coś za coś. Często lepiej zastosować progressive enhancement / graceful degradation. I nie przejmować się tym, że na bardzo starej, bardzo słabej przeglądarce nie ma gradientu lub okrąglutkich narożniczków.
Tym bardziej, że strona tak czy siak NIE BĘDZIE wyglądać tak samo na każdym urządzeniu. Przeglądarka Lynx nie zapewni gradientów ani nawet obrazków ;). Nawet na iPhonie, z retiną i dobrą przeglądarką Safari witryna będzie wyglądała zupełnie inaczej niż na 24-calowym ekranie. Witryna oglądania na małym laptopie z rodziałką 1024x768 będzie wyglądała inaczej niż w HD, choćbyśmy stanęli na głowie (w HD będzie miała po bokach więcej przestrzeni lub linie tekstu będą szersze).
Przeglądarki nieco inaczej renderują tekst, głównie ze względu na inne algorytmy wygładzania. Ale zalety web fontów są tak duże, że nie opłaca się na siłę niwelować tych różnic i zastosować Cufona (który nie umożliwia nawet zaznaczenia tekstu!), czy -- nie daj Boże -- sIFRa (wooolny, trudny w utrzymaniu i często nie działający jak należy; no i nie działa bez Flasha, np. na mobilnych platformach Apple).
Co więcej, wytyczne dotyczące użyteczności (choćby te od Jakoba Nielsena) zalecają na przykład, by używać domyślnego wyglądu kontrolek dla danej platformy. Nawet na PC-ie przyciski formularzy będą wyglądały inaczej w Firefoxie i Safari. Części z tych różnic -- np. dotyczących kontrolki input[type=file] -- nie da się poprawić za pomocą CSS. Trzeba nad kontrolką rysować element, który ją udaje, który da się stylować i który przekazuje żądania do prawdziwej kontrolki, która pozostaje ukryta.
Nowoczesne podejście do projektowania i implementowania witryn i aplikacji www nakazuje przyznanie tego, że witryna NIE BĘDZIE wyglądała wszędzie tak samo. Jeśli nie możesz pokonać wroga, to go polub. Dzisiaj trend idzie w kierunku Mobile First -- co się wiąże z bardzo prostymi, ale też bardzo użytecznymi interfejsami -- oraz Responsive Web Design, które wręcz specjalnie wyświetla witrynę inaczej na różnych platformach. Po to, by dostosować stronę do środowiska, w którym pracuje użytkownik. Nawet na niewielkim laptopie możemy mieć nieco inne oczekiwania niż na dużym ekranie w HD lub w jeszcze większej rozdzielczości.
0
- Czy to, że kod nie działa w IE7 (tak jak w innych przeglądarkach) oznacza, że zawiera babole?
Zależy od klienta i projektu.
Co do Cufona - kawał gówna, niejeden webmaster się przez to pociął.