Czy jest korzyść z wykonania makiety pełnego obrazu w porównaniu do nurkowania bezpośrednio w pisaniu HTML / CSS?

W przeszłości wiele firm i projektantów stron internetowych miało przepływ pracy składający się z dwóch lub trzech części, minimum - projektowanie, znaczniki, backend. Są uogólnione, a linie mogą się nieco rozmazać ... ale jestem pewien, że rozumiesz.

Często projektant stron internetowych był „tylko wizualny” i byłby odpowiedzialny tylko za stworzenie bardzo szczegółowej makiety w oprogramowaniu do edycji obrazów, takim jak Photoshop lub Fireworks. Makiety pokazywałyby każdy możliwy aspekt strony internetowej, od kolorów i wyborów typu, po tła, ikony, zdjęcia i inne obrazy, które mają być użyte. Ale „projektant” nigdy nie był zainteresowany rzeczywistą budową i wdrożeniem na żywo. Byli skupieni wyłącznie na wyglądzie.

Po zatwierdzeniu projektu (poprzez przegląd tych plików graficznych) przeprowadzono drugi etap - przeniesienie plików z obrazami do HTML / CSS na żywo.

• W środowisku jednoosobowym lub zewnętrznym projektant stron internetowych mógł używać plasterków i eksportować do HTML za pomocą niektórych wewnętrznych opcji aplikacji. W rzadkich przypadkach projektant może konstruować podstawowe ramki stron HTML / CSS.

• W niektórych środowiskach korporacyjnych, te makiety pozostanie w postaci warstw pliku obrazu (.psd, .png [dla Fireworks]) dla projektanta stron internetowych i projektant będzie nigdy martwić o realizacji jakichkolwiek znaczników lub kodu. „Projektant” nigdy nie musiał się martwić o to, jak skonstruować HTML lub CSS, aby zaimplementować utworzoną przez siebie makietę obrazu. Pliki graficzne zostały / są przekazane „deweloperowi”, który jest następnie odpowiedzialny za tworzenie HTML / CSS pasującego do pliku obrazu.

Wyobrażam sobie, że niektóre wciąż bardzo dużo pracy w ten sposób. Jednak dzięki postępom w językach znaczników, a mianowicie CSS3, i ulepszeniom obsługi przeglądarki - w wielu przypadkach czas spędzony na starannym tworzeniu rastrowej reprezentacji pełnej strony internetowej może być w większości przypadków bezużyteczny.

Przy obecnym znaczniku bardzo łatwo jest zrealizować wiele potrzeb związanych z projektowaniem stron internetowych bezpośrednio za pomocą HTML / CSS, a użycie aplikacji graficznej ogranicza się do generowania zasobów małych obrazów lub fotografii, które mogą być potrzebne. (Biblioteki i / lub szablony, takie jak Bootstrap, dodatkowo popchnęły to pojęcie).

W moim przepływie pracy w szczególności zrezygnowałem z pełnych makiet stron, chyba że są one specjalnie wymagane. Robię to, aby poprawić szybkość projektowania i upewnić się, że to, co jest zatwierdzone, jest bliskie temu, co zostanie ostatecznie renderowane w przeglądarkach. W rzeczywistości od wielu lat nie stworzyłem pełnej strony makiety. Ale wiem, że przy użyciu tej metody nadal istnieją przepływy pracy.

Czy jest jakaś realna korzyść z tworzenia pełnych stron makiet w aplikacji do edycji obrazów przed zanurzeniem się bezpośrednio w HTML / CSS do projektowania?

Zaletą tworzenia makiet na całej stronie jest podział pracy.

W większych firmach, które mają zarówno projektanta, jak i programistę (frontend), zadaniem projektanta jest projektowanie, a zadaniem programisty jest pisanie kodu .

Posiadanie tego podziału pozwala projektantowi poświęcić cały swój czas na pracę nad wyglądem, działaniem i interfejsem strony internetowej i nie musi wiedzieć nic o tym, jak jest tworzona. Mogą tworzyć projekty wyższej jakości i dłużej zastanawiać się nad decyzjami, ponieważ nie pracują nad tym, aby kod zrobił to, co chcą w tym samym czasie.

Pozwala także programistom pisać więcej kodu, nie myśląc o tym, jak będzie wyglądał żaden z nich, w tym małe szczegóły i różne stany. Realizują projekt najlepiej jak potrafią w danym czasie i mogą przejść do innego projektu.

Jeśli projektant jest również programistą, myślę, że większość ludzi zaczyna opowiadać się za tobą, ponieważ tworzą bardziej szorstki produkt i iterują szybko, aby to sprawdzić. Umożliwia to szybkie testowanie pomysłów, a nie tworzenie idealnego piksela dokumentu Photoshopa.

Jednak szorstki, iteracyjny projekt bez kodu jest również poprawnym i niezwykle przydatnym podejściem, szczególnie w przypadku układów i przepływu pracy. Języki znaczników i nowa technologia nie wymyśliły szybkiej pracy z surowymi pomysłami :)

Z tą odpowiedzią wybiorę Guffę. Żeby było jasne, nie staram się wyróżniać Guffy, ale raczej wypunktowane punkty są bardzo częste. Chciałbym również zaoferować kilka kontrapunktów. Nie twierdzę, że Guffa się myli i mam rację. Po prostu oferuję kontrapunkt.

1. Kreatywna część procesu projektowania cierpi, jeśli poświęca się czas na próbę zrobienia różnych rzeczy w HTML i CSS.

Dzieje się tak, jeśli nie uważa się kodu za równie kreatywny. Photoshop i HTML / CSS / JS są mediami, w których może pracować artysta. Tak jak farba jest tak kreatywna jak węgiel drzewny, więc Photoshop może być tak kreatywny na medium jak HTML / CSS / JS.

Wielką zaletą bezpośredniej pracy w HTML / CSS / JS jest wielowymiarowość. Na koniec Photoshop to płaskie płótno. HTML / CSS / JS to dynamiczne płótno z płynnością, interakcją, animacją itp.

Podsumowując, twierdzę, że kod jest w tym przypadku bardziej kreatywnym medium.

2. Kiedy projektanci i koderzy to różni ludzie, nawet jeśli projektanci są całkiem dobrzy w HTML i CSS, rzadko są naprawdę dobrzy w kodowaniu. Rezultatem byłby (w różnym stopniu) niewydajny kod, który jest nadęty i trudny do utrzymania.

Niestety kontrapunktem jest to, na co często wpadam: większość programistów pracujących w dedykowanych rolach pracuje w większej organizacji (gdzie dedykowane role są bardziej normą), a także z powodu braku wiedzy interdyscyplinarnej ( i często całkowity brak kodu warstwy prezentacji) sprawia, że ​​niektóre z najbardziej rozdętych są trudnym do utrzymania kodem frontonu, jaki kiedykolwiek widziałem.

Chodzi o to, że nie uważałbym swoich zdolności w zakresie projektowania wizualnego za jakiekolwiek wskazanie ich umiejętności kodowania. Chciałbym pójść o krok dalej i argumentować, że utalentowany generalista, który zna się na projektowaniu i kodowaniu - nawet jeśli nie jest najlepszym projektantem ani najlepszym programistą, często może stworzyć lepszy ogólny produkt niż wysoce oddzielny zespół po prostu z tego powodu że widzą większy obraz podczas tworzenia. W tłumaczeniu traci się znacznie mniej.

3. Jeśli zaczniesz pisać kod, zanim będziesz mieć jasny obraz tego, jak powinien wyglądać projekt, dokonujesz niedoinformowanych wyborów dotyczących sposobu budowy kodu. Istnieje ryzyko, że pogorszy kod i ograniczy możliwości projektowania.

Ale projektowanie w kodzie nie oznacza, że ​​to twój kod produkcyjny. Pracowałem nad projektami, w których większość kodu, który stworzyliśmy, była przeznaczona wyłącznie do całkowitego zaprojektowania, a następnie wykonania prototypów. Po zakończeniu dokonamy czystego przepisania. Dzięki temu mogliśmy znaleźć wiele „gotchas” w pierwszej rundzie kodowania.

4. Kod HTML i CSS może się bardzo zmienić przy niewielkich zmianach w projekcie, co uczyniłoby proces projektowania bardziej statycznym. Ryzykujesz ograniczenie się do zmian, które łatwo wprowadzić w kodzie.

Argumentem przeciwstawnym jest to, że projektant ogranicza się tylko do zmian, które można łatwo wprowadzić w Photoshopie. W każdym razie nie jest to zbyt dobry argument.

Jedynym powodem, dla którego najpierw nie należy wykonywać makiety programu Photoshop, jest to, że projektant nie rozumie ograniczeń kodu. Nigdy nie chcesz dać klientowi porównania czegoś, czego nie może mieć w finale.

Tak długo, jak PSD reprezentuje coś, co można dość ściśle powielić w CSS / HTML (biorąc pod uwagę ograniczenia między przeglądarkami i różne media), robiłbym to w Photoshopie (lub InDesign - znam kilku projektantów, którzy się w tym komponują). Szybsze i znacznie łatwiejsze jest manipulowanie obrazami. Naśladowanie w CSS byłoby dla mnie kodowaniem przed kodowaniem, jeśli ma to sens.

Istnieje kilka przyczyn oddzielenia elementu projektu od elementu generującego kod, na przykład:

• Kreatywna część procesu projektowania cierpi, jeśli poświęca się czas na próbę zrobienia różnych rzeczy w HTML i CSS.

• Kiedy projektanci i koderzy to różni ludzie, nawet jeśli projektanci są całkiem dobrzy w HTML i CSS, rzadko są naprawdę dobrzy w kodowaniu. Rezultatem byłby (w różnym stopniu) niewydajny kod, który jest nadęty i trudny do utrzymania.

• Jeśli zaczniesz pisać kod, zanim będziesz mieć jasny obraz tego, jak powinien wyglądać projekt, dokonujesz niedoinformowanych wyborów dotyczących sposobu budowy kodu. Istnieje ryzyko, że pogorszy kod i ograniczy możliwości projektowania.

• Kod HTML i CSS może się bardzo zmienić przy niewielkich zmianach w projekcie, co uczyniłoby proces projektowania bardziej statycznym. Ryzykujesz ograniczenie się do zmian, które łatwo wprowadzić w kodzie.