12 декабря 2010 г.

Истинный 3D-экран

На днях мне приснился сон, в котором у меня было устройство (во сне я думал, что это смартфон), который обладал истинным, самым настоящим и реальным 3D-экраном.
Выглядело это так.
Я решил посмотреть какую-то городскую местность. Для этого достал устройство, запустил на нём навигационную программу и что-то в ней нажал. В результате из экрана "вылезли" дома и организовали что-то типа макета. Все дома были разные (по высоте и форме). Самый высокий дом был примерно 15 сантиметров. Все дома были не прозрачные, однотонные, сероватого цвета.
Конечно, первым моим желанием было прикоснуться к этим домам. :) На ощупь они были похоже на чистый лёд, но абсолютно не холодные и менее мокрые. И хотя ощущались они как мокроватые, тем не менее руки оставались сухие. При более сильном нажатии на дом, он моментально превращался в жидкообразное состояние (как вода) и падал на экран. Но при этом абсолютно не разбрызгивался. Упавшая жидкость моментально исчезала (впитывалась) в плоскости экрана.
При наклоне экрана ничего не вытекало. :)
Для вращения карты использовались стрелки рядом с экраном. Причём если при вращении карты какой-то дом должен был выйти за край экрана, то он также, как и при нажатии, падал, не выходя за границу. С другого же края "вырастали" новые дома.
Самое главное: хотя эти дома не обладали детализацией (на них не было никаких окон, дверей и прочих архитектурных особенностей - это были просто прямоугольники), тем не менее, эту местность можно было как угодно рассмотреть.
Не знаю, почему мне приснился такой детальный сон про такой экран. :)

25 октября 2010 г.

Игры со свободной песочницей

Поиграл я в очередную 3D-игру, где игроку предоставляется абсолютная свобода перемещений. И понял, что истинной свободы в играх у меня (и не только у меня) нет и никогда не было. Заметить это можно, на пример, по диалогам: игроку предоставляется выбор из ограниченного числа ответов, которыми он может воспользоваться. Но что делать, если я хочу ответить другое?
Именно по этому я и не доиграл последнюю игру - в ней я, как игрок, вроде бы должен являться непосредственным участником, от решения которого зависит вся дальнейшая линия игры, но на самом деле моя участь сводится к безвольному выбору из предоставленных вариантов поведения.
Более того, часть моих ответов звучит так, что я сам не понимаю, что же я этим пытаюсь сказать. :)

24 октября 2010 г.

Развитие робототехники

Предполагаю, что развитие робототехники может быть продвинуто производителями раличных протезов (механических, электрических).

6 октября 2010 г.

Чтение блогов

Сейчас большинство блогов (хотел написать "все", но возможно я просто не все встречал) предоставляют такой режим чтения, когда новые сообщения появляются наверху.
Таким образом, если блог публикует связанные между собой сообщения, то в браузере это будет выглядеть, например, так:
03 марта.
Вернулся из отпуска.

02 февраля.
Я в отпуске.

01 января.
Поехал в отпуск.
Так, посетитель этого примерного блога, первый раз зашедший на этот блог, первым делом узнает о последнем событии - о возвращении из отпуска. Ну, это ещё не сильно критично - ведь не будет посетитель перечитывать весь блог. :)
Другой же посетитель, который изредка посещает этот блог, если зайдет на него между 02 февраля и 03 марта первым делом узнает об отпуске. ("Как? Когда уехал?") :)
Конечно, часть вины будет лежать и на владельце блога, т.к. при написании сообщений он не расчитывал на таких посетителей. Но кто на них расчитывает? :)

Теперь допустим, Вы не знаете об RSS и email-рассылках. Т.е. блог Вы читаете единственно доступным способом: путём посещения страницы блога с помощью браузера.
Незавидная участь ждёт читателей.

Предлагаю добавить в блоги автоматическое скрывание прочитанных сообщений. Выглядеть это может примерно так: посетитель заходит в блог; браузер отслеживает сообщения, по которым посетитель прошелся, и где-то (например, в cookies) помечает их как прочитанные. Когда посетитель заходит в блог в следующий раз, то ему уже отображаются только непрочитанные сообщения.
Таким образом, можно установить более правильный режим чтения, когда новые сообщения в блоге появляются снизу.

10 сентября 2010 г.

Виртуальные рабочие столы

В *nix-системах довольно популярна идея (и реализация в рамках дистрибутива OS) виртуальных рабочих столов.
В win-системах это реализуется только сторонними приложениями.
Наличие единственного рабочего стола больше соответствует понятию "рабочий стол", используемому в реальной жизни: посмотрите на свой рабочий стол, на котором стоит Ваша клавиатура (ноутбук, книжка, кружка ... :) ) - сколько столов вы видите? :) Получается, что в реальной жизни Вам хватает одного стола, а в виртуальной - нет. :)
Основным удобством виртуальных рабочих перед реальными (из реальной жизни) является возможность переключаться между различными активностями: например, на одном столе можно "обложиться учебниками и писать диплом", а на другом "пить чай с плюшками". В реальной жизни нам пришлось бы либо ходить от стола к столу, либо объеденить эти активности, и рисковать "залить диплом чаем". :)
Тем не менее, мало кто из нас может одновременно (именно одновременно) работать плодотворно сразу на двух столах: писать диплом, глядя в книгу, и пить чай с плюшкой - либо мы смотрим в книгу, либо в кружку; либо мы держим ручку, либо кружку. Происходит постоянно переключение внимания.
Нет, чай-то мы, конечно, попьём, но получим ли мы от этого удовольствие? :) И уж точно, на время совмещения, у нас снизится скорость написания диплома.
Предлагаю не создавать одновременно множество виртуальных столов, а иметь один, но при необходимости выгружать его и загружать другой. Например:
  • включили компьютер и сразу выбрали нужный рабочий стол (с дипломом);
  • поработали за ним - записали состояние стола, выгрузили, выбрали и загрузили другой стол (с чаем и плюшками);
  • попользовались другим столом - записали состояние, выгрузили, выключили компьютер.
Т.е. стол один, но дел, которых мы за ним можем сделать - несчётное множество. И главное - эти дела не мешают друг другу.

7 сентября 2010 г.

Управление вводом/изменениями данных на формах

Сейчас в системах Windows (другие не рассматриваю, ибо не знаю как "там" сейчас) принята следующая идеология при вводе или изменении данных на формах: пользователю предоставляются 3 (не всегда) кнопки:
  • OK - применяет все изменения на форме и закрывает форму;
  • Apply - применяет все изменения на форме и оставляет форму открытой;
  • Cancel - отменяет все изменения на форме, которые были сделаны до последнего нажатия кнопки Apply.
Но иногда бывает полезно ввести/изменить данные, посмотреть как это "выглядит", и затем отменить ввод. Для выполнения этого сейчас надо выполнить следующие действия:
  1. Открыть форму и ввести/изменить данные.
  2. Нажать OK или Apply (в последнем случае нам не надо будет закрывать форму).
  3. Посмотреть полученный результат.
  4. Опять открыть форму (или перейти на неё, если на шаге 2 мы нажали Apply).
  5. Отменить все исправления, сделанные на шаге 1.
  6. Нажать OK.
Предлагается для достижения того же результата изменить эту последовательность действий на следующую.
  1. Открыть форму и ввести/изменить данные.
  2. Нажать Apply (форма остаётся открытой).
  3. Посмотреть полученный результат.
  4. Перейти на форму.
  5. Нажать Cancel.
Т.е. нам не придётся повторно отменять (кликать по всем контролам) все исправления. Т.е. предлагается изменить фукнционал кнопки Cancel на такой, что её нажатие будет отменять все изменения, сделанные на форме, не до последнего нажатия кнопки Apply, а до момента открытия формы.

P.S. Возможно, таким образом мы потеряем какой-то другой фунционал. :)

Контроль качества

Разработчики создают программы. Отдел качества их тестирует. Пользователи - используют.
Но иногда компании экономят на отделе качества (например, выделяют недостаточное количество тестеров на проект или предоставляют недостаточное количество времени для тестирования). Таким образом роль тестеров достаётся конечным пользователям.
Предлагается.
Создаётся интернет (онлайн) сообщество тестеров, желающих заниматься тестированием на следующих условиях:
  • Разработчик перед выкладыванием проекта для тестирования, выделяет на это определённую сумму денег.
  • Тестер по желанию может присоединиться к любому проекту.
  • Необходимо гарантировать, что пользователи знают об описываемом сообществе тестеров. (???)
  • Тестер (практически по желанию, но теоретически это понадобится) знакомится с документацией по проекту.
  • Тестер по желанию может заниматься поиском ошибок в программе.
  • Если тестер(1) находит ошибку в программе, которая не соответствует функционалу (это обязательное условие), описанному в документации, то он сообщает о ней в сообществе.
  • Если другой тестер(2) видит, что кто-то нашел ошибку, то он может проверить её: действительно ли ошибка имеет место быть.
  • Если ошибка подтверждается, каждый тестер получает определённое, но различное количество баллов.
  • Если ошибка не подтверждается, то инициируется процедура судейства (???), после которой с какого-нибудь тестера (или с обоих) могут снять часть баллов.
  • Найденная ошибка уходит разработчикам (на исправление).
  • Разработчик также может быть не согласен с наличием ошибки (???).
  • После завершения этапа тестирования, начинается этап опытной эксплуатации пользователями.
  • Если пользователь находит ошибку, он сообщает о ней в сообщество тестеров.
  • Каждая найденная пользователем ошибка также обрабатывается на соответствие документации, с привлечением, при необходимости, процедуры судейства. (???)
  • Если ошибка подтверждается, то со всех тестеров, участвующих в проекте, снимается определённое количество баллов, а пользователь, нашедший ошибку, наоборот, получает определённое количество баллов.
  • После завершения этапа опытной эксплуатации, выделенная разработчиком на тестирование сумма, делится между тестерами и пользователями, в соответствии с набранными ими баллами.
Знаками "???" пометил места, которые требуют дополнительного обдумывания.