Projektowanie stron WWW od podszewki

Artykuły na każdy temat

Komunikator idealny - mały wywód

Dodano 29.11.2010r. o 08:08
We wpisie przedstawię moją wizję i przemyślenia dotyczące tego jak powinien wyglądać komunikator idealny albo co najmniej dobry. Swoje słowa kieruje głownie do osób choć trochę zorientowanych w dziedzinie informatyki. Jeżeli jesteś fanatycznym użytkownikiem Padu-Padu w wersji większej niż 7 i jesteś dumny z tego faktu to możesz od razu opuścić stronę, gdyż z góry jesteś skazany na wymarcie.

Jako internauta, programista i obserwator miałem dużo czasu aby przetestować rożne kanały komunikacji. Przez około 10 lat sprawdziłem większość komunikatorów dostępnych na rynku i doszedłem do wniosku, że żaden z nich nie zasługuję na miano dobrego. Zawsze znajdzie się mankament, który dyskwalifikuje aplikacje. Zacznijmy od prostej teorii. Komunikator idealny powinien charakteryzować się takimi rzeczami:
  1. Po pierwsze uniwersalny protokół komunikacji niezależny od używanej aplikacji. W ten oto sposób to użytkownik będzie wybierał najlepsza dla niego aplikacje, a nie tak jak jest do tej pory, że wypromowany został jako pierwszy komunikator/standard komunikacji i większość ludzi została do niego przyzwyczajona choć z czasem się to zmienia. Zdaję sobie sprawę, że ta wizja jest nierealna gdyż w grę wchodzą duże profity i posiadanie monopolu na daną opcję to priorytetowa sprawa.
  2. Po drugie powinien cechować się kompatybilnością wsteczną. Zespół inżynierów zwany dalej programistami powinien tak projektować swój twór aby nie było problemów z funkcjonowaniem projektu. Dla przykładu jakiś czasu temu Gadu-Gadu zmieniło sposób transferowania plików co w rezultacie powoduje np. w Tlenie (wersji oznaczonej cyferka 6) zawieszanie się programu w momencie zaakceptowania przesłania pliku. Sytuacja zawieszenia aplikacji ma miejsce do czasu kiedy użytkownik nie anuluje transferowania danych. Geniusz nie ma granic bo przy okazji można odkryć brak ogarnięcia ze strony programistów Tlenu. Mianowicie przesyłanie plików powinno odbywać się w oddzielnym wątku.
  3. Po trzecie protokół powinien być tak skonstruowany, żeby powyżej 17 milionów użytkowników nadal można było się komunikować ze wszystkimi, a nie tak jak to ma miejsce teraz, że są straszne zgrzyty i wiadomości nie dochodzą albo dochodzą przez jakiś numer zwany dalej bramka... Jakby nie można było normalnie wysyłać wiadomości?!? Oczywiście mowa o sytuacji związanej z Gadu-Gadu.
  4. Po czwarte przesyłanie plików powinno być zrobione na wzór tego, które występuję w komunikatorze Windows Live Messenger (MSN). Mówiąc wprost, chodzi o mechanizm przeciągnij i upuść (ang. drag and drop) czyli przeciągamy plik w okno rozmowy i odbiorca ma dwie możliwości manewru. Może zaakceptować transfer albo anulować. Limit przesyłanych plików powinien być rozegrany tak samo jak w MSN czyli jego wysokość powinna być zależna od prędkości wysyłania nadawcy. Im większy transfer posiadamy tym więcej plików możemy wysyłać w jednym czasie. Warto tutaj zastanowić się także nad kwestią tego ile taki transfer może trwać. Najlepiej byłoby gdyby pliki o znacznej wadze były przesyłane pojedynczo. W ten sposób można uniknąć problemów z błędami transferu. Im większy ruch w sieci (z/do komputera) tym większe prawdopodobieństwo, że pakiet urwie się. Dlatego też w trakcie wysyłania danych powinna być sprawdzania suma kontrolna zawartości co jakiś czas aby nie dopuścić do sytuacji, w której przesłano plik z błędami. Ważną cechą takiego przesyłania powinna być możliwość kontynuacji przesyłania po przerwaniu transferu. Taka sytuacja czasami ma miejsce w chwili np. odnawiania IP przez routera bądź chwilowych problemów z swoim ISP.
  5. Po piąte nie znam lepszego komunikatora aniżeli Skype odnośnie rozmów głosowych. Myślę, że wykorzystanie technologii rodem z wyżej wymienionej aplikacji nie będzie grzechem.
  6. Po szóste protokół komunikacji powinien umożliwiać sprawdzanie statusu wiadomości dzięki czemu już nigdy nie zaginie nam wiadomość i nie będziemy musieli się potem tłumaczyć, że coś nam nie doszło bo niefortunnie zerwało połączenie.
  7. Po siódme dobrym pomysłem moim zdaniem jest umożliwienie użytkownikom stosowanie avataru. W ten sposób w ułamku sekundy skojarzymy odbiorcę bez czytania pseudonimu pod którym zapisaliśmy ofiarę.
  8. Po ósme lista kontaktów powinna być aktualizowana na bieżąco co oznacza sytuacje, w której dodanie, modyfikacja bądź usuniecie kogoś z listy kontaktów odzwierciedla się tym samym stanem na serwerze. Przykładowym miejscem występowania takiego bajeru jest MSN.
  9. Po dziewiąte autoryzacja. Jeżeli użytkownik życzy sobie aby dostawać wiadomości tylko od użytkowników z listy to trzeba uszanować jego wolę. W ten sposób stawiamy krzyżyk na drogę spamerom i innym dziwnym tworom (np. botom).
  10. Po dziesiąte filtracja ruchu i wiadomości. Nie mam tutaj na myśli łamania prawa do prywatności korespondencji lecz implementacje filtrów antyspamowych. Oczywiście nic nie jest doskonale i zawsze można przechytrzyć regułę jednak trzeba budować mechanizmy aby były jak najtrudniejsze do złamania. Rozchodzi się o wysyłanie tej samej wiadomości do dużej ilości numerów. Taki ruch powinien być karany bo zazwyczaj wiążę się z nim wysyłanie reklam.
  11. Po jedenaste to użytkownik decyduje o tym czy link jest bezpieczny bądź nie. Nie ma tu racji bytu decydowanie, a zarazem filtrowanie linków przesyłanych pomiędzy stronami.
  12. Po dwunaste komunikator powinien ułatwiać tworzenie konferencji. I tutaj pojawia się zgrzyt. Najlepiej byłoby gdyby istniały dwie formy konferencji. Jedna to typ z operatorem dyskusji, która decyduje kogo dodać do konferencji, natomiast drugi typ to konferencja otwarta i dowolna osoba dołączona może dołączać kolejne. Z drugim typem wiążę się pewne zagrożenie dlatego prędkość dodawania nowych osób powinna być limitowana bądź odbiorca powinien akceptować fakt czy chce zostać dodany do konferencji. Innym sposobem zapobiegania problemów może być akceptowanie zaproszeń do konferencji jedynie od użytkowników z listy.
  13. Po trzynaste komunikator powinien umożliwiać multisend. Termin wymyślony specjalnie na tą okazję. Oznacza nic innego jak możliwość wysyłania plików do wszystkich zgromadzonych na konferencji. Według mnie zasada powinna być prosta. Źródło pierwotne wysyła plik(i) do odbiorców zgodnie ze swoimi możliwościami. W praktyce może to oznaczać np. wysłanie pliku do jednej osoby, a następnie gdy ta osoba odbierze plik to ona również staje się źródłem czyli coś na zasadzie sieci P2P.
  14. Dobrym pomysłem będzie otwarty kod źródłowy aplikacji. Dzięki temu dowolna osoba znająca się na programowaniu będzie mogła modyfikować klienta według własnego uznania. Minimalnym rozwiązaniem, a zarazem furtką będzie udostępnienie API i możliwości pisania/uruchamiania własnych wtyczek.
  15. Innym dobrym pomysłem może być zaczerpnięcie mechanizmu udostępniania fotografii z MSN'a. Wystarczy przeciągnąć i po chwili odbiorca widzi obraz w oknie rozmowy. Co najważniejsze nie w miejscu gdzie tekst się pojawia tylko w osobnym fragmencie dzięki czemu będzie można zminimalizować udostępnioną fotografię. W ten sposób nie trzeba będzie przewijać rozmowy aby zobaczyć jakąś grafikę.
  16. Niedawno czytałem blog gadu gadu i ktoś rzucił pomysłem aby identyfikatory były w formie numeru_bądź_nicku@gg.pl. Moim zdaniem taki pomysł nie jest głupi gdyż ułatwi zapamiętywanie swojego loginu.
  17. Cztery podstawowe statusy powinny w zupełności wystarczyć przeciętnemu pożeraczowi internetu.
  18. Zastanawiam się nad brzęczykiem rodem z MSN'a. Możliwe, że jest to dobry pomysł o ile nie będzie nadużywany. Kwestia ustawień?
  19. Opisowy status powinien mieścić się w 255 znakach przy czym komunikator powinien mieć możliwość usuwania znaku nowej linii w opisie.
  20. Czasami zdarzają się nam osoby na liście, które maja problemy ze swoim ISP. Komunikator powinien umożliwiać czasowe mutowanie. Mam na myśli wyciszanie dźwięku dla konkretnej osoby gdy ta cyklicznie pojawia się i znika.
  21. Moim zdaniem zakazane powinno być szybkie zmienianie stanu dostępności. Przez chwile pomyślałem o takim bajerze, który pokazywałbym mniej więcej aktywność danego użytkownika. Niestety ma to swoją wadę, gdyż można byłoby kogoś szpiegować i pilnować czy siedzi przy komputerze i rusza myszą Wink Tak więc odpada.
  22. Inną priorytetową cechą charakterystyczną powinna być prawidłowa optymalizacja. W czasach kiedy komputery były słabe programista walczył o każdy bajt zajmowany przez program w pamięci komputera. Dzisiaj w świecie przekokszonych pieców optymalizacja zeszła na dalszy plan. Przykładem jest oficjalny klient Gadu-Gadu, który zajmuje dużo ponad 200 koła bajtów O_o Takie rzeczy są chore i powinny być leczone na psychiatryku przez wybitnych specjalistów aby żaden programista nie myślał, że to normalne dla programu, który ma umożliwiać tylko rozmowę z drugą osobą!
  23. Tutaj coś co wyleciało mi z głowy Sad
  24. Jedna rzecz mi się przypomniała ale to nie ta co wyleciała piętro wyżej. Niedopuszczalnym zjawiskiem jest sytuacja, w której wysyłane są reklamy pomiędzy naszymi wypowiedziami. Tak karygodna sytuacja powinna być iskrą zapalną dla wszystkich użytkowników, że czas najwyższy zmienić platformę komunikacyjną!
  25. Nieaktywne identyfikatory pozostawione przez dłuższy czas powinny być wrzucane do puli, z której ktoś inny mógłby z nich skorzystać. W ten sposób zostanie zachowana naturalna kolej rzeczy, a nie sztucznie podbijana statystyka.
  26. Komunikator powinien mieć także możliwość udostępniania tego co widzi nadawca czyli coś ala TeamViewer bądź dzielnie się ekranu rodem ze skrzypa (Skypa).
  27. Nie wolno zapominać o obsłudze kamerki internetowej.
  28. Odnośnie funkcjonalności to komunikator powinien być tak napisany aby nie było możliwości podglądania danych profilu jak to jest w przypadku config.dat
  29. Dobry komunikator powinien się także charakteryzować dobrą obsługą archiwum. Oczywiście po stronie klienta bo strona serwera to już inna bajka. Plik archiwum powinien być tak skonstruowany aby osoba postronna nie mogła go po prostu skopiować i odczytać. Z drugiej zaś strony przy przyzwoleniu właściciela archiwum powinno dać się eksportować do formatu XML.
  30. Naturalna rzeczą jest utrzymanie projektu w ryzach. Mam na myśli kwestie finansowe czyli mówiąc wprost opłacalność przedsięwzięcie. Żeby nie było jak z Gadu-Gadu czyli pazerność na mamonę. Jedną kwestią jest baner w oknie rozmowy, który można zrozumieć. Te 50 czy 100 tysięcy złotych na dobę można zrozumieć ale nie ekstra migające flashe i gify obok listy kontaktów. Poza tym reklama w głównym oknie reklamy powinna w zupełności wystarczyć na utrzymanie serwerów, opłacenie ludzi i zaspokojenie swoich poniekąd chorych potrzeb.
  31. Dobry team zajmujący się komunikatorem powinien cechować się także reakcją na pomysły ze strony użytkowników. Najlepszym przykładem jest blog Gadu-Gadu, w którym pracownicy korporacji nigdy nie odpowiadają. Ludzkim zachowaniem powinna być interakcja ze swoimi podopiecznymi.
  32. Prawidłowo zbudowany komunikator powinien być także elastyczny i przy pomocy jak najmniejszego wysiłku dawać się dostosowywać do potrzeb użytkownika. Głównie chodzi mi o wygląd.
  33. Ponadto interfejs powinien być intuicyjny dzięki czemu użytkownik nie będzie tracił zbędnego czasu na szukanie funkcji X z działu Y.
  34. I chyba najważniejszy punkt z listy. Komunikator to komunikator, a nie stacja radiowa, telewizyjna i bóg wie co jeszcze... Wszelkie dodatki typu gry, chaty, sklepy internetowe, niusy z pierwszej ręki są stanowczo nie na miejscu!!!

Jeżeli macie jakiekolwiek sugestie odnośnie listy, zgadzacie się bądź nie zgadzacie z którymś z punktów byłbym wdzięczny gdybyście zamieścili takie uwagi w komentarzach poniżej artykułu Smile Myślę, że wspólnymi siłami można zawsze dojść do konsensusu.

Komentarze

Publikowane komentarze są prywatnymi opiniami użytkowników serwisu. Serwis nie ponosi odpowiedzialności za treść opinii. W trosce o zachowanie poziomu dyskusji wszystkie komentarze podlegają akceptacji przed ich publikacją dlatego proszę cierpliwie czekać aż komentarz zostanie opublikowany.

CapaciousCore

Dodano 30.11.2010r. o 18:12
Poprawione, dzięki za uwagę.

[Edytowano 2010-12-08 18:16]
Pomyślałem sobie, że dobrym pomysłem byłby wbudowany słownik podkreślający błędy. Odnoszę także wrażenie, że zapomniałem także wspomnieć o szyfrowaniu wiadomości.

Sobak

Dodano 30.11.2010r. o 18:09
Dobre pomysły, z tym, że niestety duża część z nich jest niewykonalna ze względu na chciwość, lenistwo i pazerność na dane osobowe.

Co do ostatniego pkt. to takie rzeczy mogą jak dla mnie występować ale tylko w formie wtyczek (chociażby oficjalnych wydawanych przez autora programu).

I jeszcze jedno spostrzeżenie - literówka w pkt. drugim. "cechować się kontatybilnością wsteczną"

Dodaj komentarz

Zostaw komentarz jeżeli możesz! Nie bądź przysłowiowym botem! Nie bądź obojętny! Ciebie to nic nie kosztuje, a mi sprawi uśmiech na twarzy.
Zezwolono używać: BBCode
Zabroniono używać:
znaczników HTML

(Wymagany)

(Wymagany, niepublikowany)

(Nie wymagana)

Token:

Obrazek dla bota

(Przepisz tylko cyfry!)

(Wymagana)