Не только содержание, но и расположение подписи несёт информацию о помещении.

Самое очевидное — это подписать посередине двери на уровне глаз. Просто какой-то кабинет, без постоянного потока посетителей:

Если это аудитория в университете или комната в общежитии, то лучше сделать цифры крупнее, ведь люди ищут их именно по номеру:

Если у нас техническое помещение, в которое вообще ходят лишь изредка специально обученные люди, можно подписать его мелко на косяке:

Естественно, у двери может быть текстовая подпись:

Обычно нужно, чтобы была и текстовая подпись, и номер. Хорошо найти места для того и другого, чтобы они не мешали друг другу:

Может оказаться, что у каких-то помещений не будет подписи, а будет только номер или наоборот, так что надо, чтобы они могли использоваться независимо.

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

Кстати, туалеты вообще удобнее обозначать иконками:

Туалеты, а также двери к лестницам и лифтам ищут все люди, независимо от целей визита. Имеет смысл выделить их торчащими табличками, чтобы было видно при перпендикулярном движении по коридору:

Дверь к проктологу, в серверную или в туалет, скорее всего, обычно будет закрыта. Но если это переговорка или столовая, дверь легко может быть часто открытой нараспашку, и тогда никто не увидит, что на ней написано:

Если нужен только номер, его можно разместить и над дверью:

Но читать на такой высоте текст уже не очень удобно. Подпись лучше разместить сбоку:

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

Если номер нужен, но используется редко, его можно снова поставить на косяк:

В реальном здании всегда будут разные двери, и к ним будут применимы разные соображения. Выбрать единое расположение для всего получится редко. Но это не баг, а фича: как я сказал в начале, само расположение подписи уже несёт информацию о роли помещения. Если ты пациент в поликлинике, то тебе не нужна раздевалка для сотрудников, и она может быть подписана лишь мелким номером в углу. А вот кабинеты врачей могут быть пронумерованы крупнее, ведь тебя направляют именно по ним.

При разработке системы навигации нужно проанализировать все эти случаи, сценарии, категории посетителей, а потом как-то классифицировать двери и придумать систему.

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

А какая-нибудь дверь будет выглядеть так, что всем и без текста понятно, что без острой необходимости лучше даже мимо не проходить.

Никита Прокопов написал, что импликация — нифига не интуитивная штука, и поэтому её нет в языках программирования. И действительно: там в комментариях начался обмен мнениями, который хорошо иллюстрирует неинтуитивность. И мне сразу захотелось написать этот пост.

Импликация — это логическая операция вида «A → B». Она истинна во всех случаях кроме одного: когда A истинно, а B ложно. Можно оценить по таблице истинности:

То же самое можно сформулировать как «из истины следует истина, а из лжи — что угодно».

Кажется, что это простая штука, ведь в жизни мы легко понимаем выражения типа «Если A, то B» или «Из A следует B». Но если сказать, что «из 2×2=4 следует что Волга впадает в Каспийское море» (V), большинство воспротивится этому. Почему, ведь с точки зрения логики это верное утверждение?

Дело тут в том, что мы не интерпретируем фразу V буквально. Мы видим, что в общем случае из математического равенства не следует географический вывод. То есть мы подсознательно обобщаем V, превращаем в шаблон, и тогда импликация разрушается. Мы понимаем, что имея лишь «2×2=4» и не зная ничего про Волгу, невозможно сделать вывод о том, куда она впадает. Но импликация означает истинность конкретного этого высказывания, а не то, что высказывание сохранит истинность при обобщении.

Зачем мы вообще стали обобщать? Почему мы не можем оценить истинность импликации буквально? Потому что это низачем не нужно никогда, и наш мозг не научен так думать. Следует ли из одного высказывания другое нас интересует лишь тогда, когда мы не знаем истинности одного из них. Но если мы уже знаем истинность обоих высказываний, то у нас просто не возникает вопроса о том, как выводить истинность одного из них из истинности другого — это же совершенно бессмысленнно!

Высказывания типа «Если A, то B» нас интересуют как способ выводить истинность B из истинности A или наоборот, то есть только тогда, когда мы не знаем одно из них. А для этого нам нужно вскрыть содержательную связь между A и B, а не просто значения их истинности. Тут-то нам и нужны шаблоны, да такие, что мы уже заранее знаем, что импликация там истинна!

Предположим, мы знаем, что «у каждого голландца есть велосипед» (K). Заметьте, что это уже утверждение, содержащее импликацию («если человек голландец, то у него есть велосипед»), и мы уже договорились, что оно истинно. Вот теперь если мы узнаем, что Фёдор голландец, мы сделаем вывод о том, что у него есть велосипед. Импликация помогла сделать этот вывод только потому, что мы 1) уже знали, что сама она истинна, и вдобавок 2) она имела форму шаблона, в который можно было подставить Фёдора. От истинности же импликации V из начала заметки нет никакого проку. Поэтому с такими видами совершенно верных высказываний мы никогда не имеем дела. Они нам кажутся настолько пустыми, что мы не готовы даже пытаться оценивать их истинность.

Один из комментаторов у Никиты написал, мол, как же импликации нет в языках программирования, когда там есть if (a) b? Но что значит? В известных мне языках программирования это даже не является выражением, но если бы являлось, каким было бы его значение? Иными словами, что бы нам дал вывод print (if (a) b)? Конечно же true! Ведь в этом буквально состоит работа языка программирования: обеспечить b, когда истинно a. Если он этого не делает, то зачем такой язык программирования нужен? Но в то же время, если a ложно, то глядя на эту строчку мы никак не сделаем вывод о том, произойдёт ли b. Может, какая-то другая часть кода обеспечит b. Строчка if (a) b никак не способна предотвратить b.

Получается какая-то эзотерика, и только потому, что никто никогда не рассматривает if (a) b как логическое выражение и не пытается оценить его истинность. Всех интересует только логическое выражение a по отдельности, потому что от его истинности зависит, может ли быть уверены в том, что произойдёт b.

Импликация в языках программирования была бы, если бы можно было написать if (a→b) c, то есть «если из a следует b, обеспечь c». Но нафиг это надо? Как мы уже выяснили, когда значения a и b уже известны, значение истинности их импликации не несёт никакой пользы и почти никакого смысла.