Отличное начинание. Мне пока еще стремно выносить по настоящему важные данные в сеть, но, надеюсь, я преодолею этот страх: ) На счет возможной проблемы с подменой Javascript'а (tegger писал) — может, есть возможность сделать стэндэлон клиент — маленький портабельный экзешник, который можно было бы таскать на флешке?
Пожелание по поводу дальнейшего развития: мне очень понравился минимализм интерфейса, не усложняйте его слишком сильно, пожалуйста: ) Из косметических замечаний — красная рамка выглядит уж слишком ядреной, бьет в глаза. Главная страница кажется несбалансированной по цветам — фиолетовый бэк выбивается из общей палитры, градиент в хэдере выглядит неестественно из-за перепада сатюрейшна. Ну эт так, мое мнение с колокольни: )
Антиалайзинг в Опере будет смотерться лучше на большинстве мониторов, потому что он, в отличие от современных субпиксельных технологий, не меняет цвета пикселов. Субпиксельный антиалайзинг — это шаг вперед на качественных LCD с мелким пикселом, но только для шрифтов определенного пункта. В остальных случаях эта технология себя не оправдывает :-(
Мелкий текст даже на хорошем мониторе будет слишком цветастым, а на неподходящих ЖК (и тем более — ЭЛТ) мониках артефакты будут затруднять чтение и на крупных кеглях. Политику Сафари в этом плане понять просто — таргет для данного браузера это эйпловские мониторы, которым наверняка подходит рендер Сафари.
Но Опера — это самый кроссплатформенный браузер, и, по моему, взяв на вооружение старую технологую, Опера поступила инновационно :-).
> это все копейки для обычных пользователей
> (на ±50мс — кого это волнует?). Однако,
> если речь идет про «экономию на спичках»,
> когда нам важен каждый запрос к серверу
> и каждая миллисекунда, то тут уже стоит задуматься
Хм… Красивое заблуждение. Все ведь понимают, что рендеринг происходить на стороне клиента? Клиент, как известно, перегрузки не заметит и 50мс тормоза — тоже. Сервер тоже ничего не запметит, потому что скорость рендеринга страницы браузерами никак не влияет на скорость взаимодействия браузеров с серверами, то есть ни одна миллисикунда не будет выиграна. Зато увеличение общего веса страницы на один кб приведет к 114гб лишнего траффика в день (по некоторым данным (http://stat.yandex.ru/), на главную Яндекса приходится в среднем 120 394 270 хитов в сутки). И вот эти самые 114гб повлияют на скорость работы сервера, причем повлияют отрицательно.
Нужно оговорится — это будет очень слабое влияние, тем более что практически все мыслимые клиенты поддерживают gzip, но тем не менее — влияние отрицательное.
Рассуждая с точи зрения оптимизации, правильнее разгружать бэкенд за счет фронтэнда, а не наоборот.
Это не совсем иконки — скорее, пиктограммы. Их тут обозвали 'примитив-иконками', позволю себе не согласится: пиктограммы бывают качественными и грациозными (простота и примитивность — разные вещи), некоторые дизайнеры превращают строительство пиктограмм в искусство (http://www.iconwerk.de/), а здесь (http://www.deliciousicons.com/azur.html), например, лежит похожий, но гораздо более профессионально выполненый набор (не бесплатный: P). Однако этот сэт, выложенный на смэшинге, и в самом деле кусок говна, который портит репутацию всем пиктограммам в целом :(
1, 2 (относительные пути): Есть такой тэг - <BASE> - должен помочь.
4 (объяснить новичку): Это скорее проблема юзабилити сайта :-) На хорошем ресурсе все должно быть очевидно, если это невозможно – необходима удобная справка со скриншотами.
6. (список всех пользователей): Мне при структуре %username%.domain.com логика подсказала бы искать список юзеров (или ссылку на список юзеров) по адресу domain.com.
7. (запрещенные символы): Я не думаю что отсутствие подчеркивания более фатально для ника, чем отсутствие пробела. А если с отсутствием пробела юзеру придется мирится в любом случае, то какая разница, заменит он его дефисом или подчеркиванием? То же самое, мне кажется, можно отнести и к другим запрещенным символам.
Основную часть плюсов можно описать одной фразой - психологическая привлекательность. Людям нравится иметь персональный сайт, и убеждать их в том, что это ничуть не рациональнее каталогов – пустая трата времени.
Мне кажется разумным использовать сабдомены там, где на страничку каждого юзера люди будут заходить извне. Портфолио на фриланс.ру просматривают в основном люди, пришедшие по внутренней ссылке - они даже саму ссылку, как правило, не видят. В то же время адрес своей страницы в МоемКруге люди часто публикуют в личных блогах, комментариях, своих юзер-дитейлах в icq. И в этом случае адрес персонального сайта выглядит солиднее и логичнее папки на портале.
Пожелание по поводу дальнейшего развития: мне очень понравился минимализм интерфейса, не усложняйте его слишком сильно, пожалуйста: ) Из косметических замечаний — красная рамка выглядит уж слишком ядреной, бьет в глаза. Главная страница кажется несбалансированной по цветам — фиолетовый бэк выбивается из общей палитры, градиент в хэдере выглядит неестественно из-за перепада сатюрейшна. Ну эт так, мое мнение с колокольни: )
Мелкий текст даже на хорошем мониторе будет слишком цветастым, а на неподходящих ЖК (и тем более — ЭЛТ) мониках артефакты будут затруднять чтение и на крупных кеглях. Политику Сафари в этом плане понять просто — таргет для данного браузера это эйпловские мониторы, которым наверняка подходит рендер Сафари.
Но Опера — это самый кроссплатформенный браузер, и, по моему, взяв на вооружение старую технологую, Опера поступила инновационно :-).
> (на ±50мс — кого это волнует?). Однако,
> если речь идет про «экономию на спичках»,
> когда нам важен каждый запрос к серверу
> и каждая миллисекунда, то тут уже стоит задуматься
Хм… Красивое заблуждение. Все ведь понимают, что рендеринг происходить на стороне клиента? Клиент, как известно, перегрузки не заметит и 50мс тормоза — тоже. Сервер тоже ничего не запметит, потому что скорость рендеринга страницы браузерами никак не влияет на скорость взаимодействия браузеров с серверами, то есть ни одна миллисикунда не будет выиграна. Зато увеличение общего веса страницы на один кб приведет к 114гб лишнего траффика в день (по некоторым данным (http://stat.yandex.ru/), на главную Яндекса приходится в среднем 120 394 270 хитов в сутки). И вот эти самые 114гб повлияют на скорость работы сервера, причем повлияют отрицательно.
Нужно оговорится — это будет очень слабое влияние, тем более что практически все мыслимые клиенты поддерживают gzip, но тем не менее — влияние отрицательное.
Рассуждая с точи зрения оптимизации, правильнее разгружать бэкенд за счет фронтэнда, а не наоборот.
1, 2 (относительные пути): Есть такой тэг - <BASE> - должен помочь.
4 (объяснить новичку): Это скорее проблема юзабилити сайта :-) На хорошем ресурсе все должно быть очевидно, если это невозможно – необходима удобная справка со скриншотами.
6. (список всех пользователей): Мне при структуре %username%.domain.com логика подсказала бы искать список юзеров (или ссылку на список юзеров) по адресу domain.com.
7. (запрещенные символы): Я не думаю что отсутствие подчеркивания более фатально для ника, чем отсутствие пробела. А если с отсутствием пробела юзеру придется мирится в любом случае, то какая разница, заменит он его дефисом или подчеркиванием? То же самое, мне кажется, можно отнести и к другим запрещенным символам.
Мне кажется разумным использовать сабдомены там, где на страничку каждого юзера люди будут заходить извне. Портфолио на фриланс.ру просматривают в основном люди, пришедшие по внутренней ссылке - они даже саму ссылку, как правило, не видят. В то же время адрес своей страницы в МоемКруге люди часто публикуют в личных блогах, комментариях, своих юзер-дитейлах в icq. И в этом случае адрес персонального сайта выглядит солиднее и логичнее папки на портале.