Отдельные заголовки / навигации в одном приложении? -- navigation поле с участием header пол ux Связанный проблема

Separate headers/navigations in the same app?


1
vote

проблема

русский

первый контекст. Таким образом, моя организация находится в процессе переключения наших структур JS (от угловых для реагирования) и, возможно, даже в Backend Technologies для нашего веб-приложения. У нас нет времени / ресурсов, чтобы просто остановить и переделать приложение все сразу, поэтому необходимо будет переход между технологиями. Предлагаемая стратегия заключается в том, что, с далее, каждый новый раздел / функция будет разработан в реакции при сохранении старых сечений в угловом углу (для переключения в конечном итоге).

Мой вопрос, вместо того, чтобы попытаться дублировать пользовательский интерфейс в новые разделы, и пытаться «обмануть» пользователю на мысль, что новые разделы точно такие же, как старые разделы (и все вопросы обслуживания, которые идут с этим ), будет ли это кошер, если бы новые разделы были полностью отдельным объектом? Новый заголовок, чистый вид, улучшенные цвета ... и т. Д. Эта реализация была бы легче с технической точки зрения, но с точки зрения дизайна, я также могу видеть преимущества. Я мог перепроектировать макет и навигацию и не нужно беспокоиться о обратной совместимости.

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

Я думал, что это будет выглядеть что-то подобное:

Старые разделы vs новый раздел

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

Спасибо заранее.

Английский оригинал

First some context. So my organization is in the process of switching our JS frameworks (From Angular to React) and possibly even backend technologies for our web app. We don't have time/resources to simply stop and redesign the app all at once, so there will need to be a transition between technologies. The proposed strategy is that, from now on, each new section/feature will be developed in React while maintaining the old sections in Angular (to be switched over eventually).

My question is, rather than attempt to duplicate the UI in the new sections, and trying to 'fool' the user into thinking the new sections are exactly the same as the old sections (and all the maintenance issues that go with that), would it be kosher if the new sections were a totally separate entity? New header, cleaner look, improved colors... etc. This implementation would be easier from a technical point of view, but from a design point of view, I can see benefits as well. I could redesign layout and navigation and not have to worry about backward compatibility.

Of course, there is the concern of disorientation, but I believe it's possible to communicate the new section is a part (though obviously separate) of the rest of the app. Of course, we would always offer a way back to the old app.

I was thinking it would look something like this:

Old Sections vs New Section

I was just curious if anyone was familiar with any other apps doing something similar. Is this particular technique have a name?

Thanks in advance.

     
   
   

Список ответов

1
 
vote

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

не ставить слишком тонкую точку на нем.

удобство использования

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

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

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

Изменение допуска между нашими пользователями низкая

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

Согласие продукта

Но даже хуже этого, потому что вы также планируете

Резервный макет и навигация и не нужно беспокоиться о обратной совместимости.

... что означает, что навигационные структуры будут в конфликте; Разделы, которые должны быть удалены из старого дизайна, будут недоступны с страниц, которые имеют новый дизайн и наоборот. Пользователю придется запомнить такие вещи, как «OK, чтобы вернуться к этой старой функции с этой новой страницы, я должен нажать на одну из ссылок на NAV, которые я помню, случается, чтобы указать на старый дизайн, чтобы я мог добраться до старого Navbar, которая ссылается на то, что я на самом деле хочу добраться до. О, подождите, я думаю, они обновили эту страницу сейчас. Как мне вернуться к старому дизайну? Где я? "

Или альтернативно, вам придется сохранить и поддерживать все «старое» приложение на протяжении всего перехода, так что у вас есть надежный отпаньку для отсутствующих частей неполного «нового» приложения. Это было бы эффективно так же, как просто пересматривая весь новый продукт за кулисами и нарезанию на ровную день, за исключением гораздо сложнее, потому что вам придется поддерживать как публично на протяжении всего перехода.

Но вы не можете этого сделать, либо,

Из-за обширной базы данных редизайн, который участвует в этом проекте ... Было бы невозможно (или, по крайней мере, нежелательно), чтобы поддерживать оба одновременно

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

Профессионализм

У нас нет времени / ресурсов, чтобы просто остановить и переделать приложение все одновременно

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

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

Нет необходимости белоблон далее, я думаю.

Так .... вместо этого ...

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

Это, как, как, совершенно полный фактор риска Bingo Card, даже если вы устанавливаете факторы UX, этот ответ выпускается.

Вам нужно отделить эти процессы, для собственной безопасности и здравоохранения, а также у ваших пользователей. Не пытайтесь сделать все одновременно; Вы потерпите неудачу.

Если вам нужно изменить фреймворки, я предложил сначала завершить этот переход, без учета каких-либо изменений в функциональности, макете или структуре. Это будет иметь тенденцию сделать код переходом намного быстрее и более быстрее и более быстрым, чем если вы пытаетесь внести другие изменения одновременно. (Это также будет иметь случайное преимущество в том, чтобы ваши разработчики получили решение о том, как работает работает, прежде чем они должны будут копаться на «реальном» новом дизайне; они будут делать свое обучение на версии, которую вы планируете выбросить, Вместо в коде вы будете жить с длительным сроком.)

Некоторые изменения структуры базы данных, вероятно, продолжаются с необходимостью, но сохраняйте их как можно минимально.

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

Особенно с резистентной аудиторией, мне нравится делать это на двух отдельных этапах:

  1. косметические изменения. Если они являются основными, сделайте их все сразу. Скала, что новый вид и чувствуют, переместите макет, как сумасшедший, но держите всю функциональность и иерархию навигации точно так же, поэтому пользователь не чувствует себя потерянным; Это тот же продукт, он выглядит красивее. Это то, что будет восприниматься пользователями как настоящий редизайн, хотя он функционально идентичен тому, что было там раньше.
  2. Функциональные изменения, постепенно. Реструктурируйте свою карту сайта по мере необходимости, измените функциональные возможности, которые нуждаются в изменениях, но делайте их постепенно и постепенно. Вот где происходит реальные изменения, но пользователи, как правило, не будут восприниматься пользователями как «редизайн», потому что все это выглядит одинаково - биты и кусочки, которые просто работают лучше каждый раз, когда вы выполняете обновление. Это постепенно означает, что у вас есть возможность получить отзывы пользователя, как вы идете, и откидываете ошибки, прежде чем вы привержены их слишком сильно. Это также смягчает изменение сопротивления со стороны пользователя, потому что вы не изменяете все на них, вы просто улучшаете биты и кусочки.

 

This would be an ongoing slow-motion fireball of a disaster, in terms of usability, product coherence, and user trust in your company's capabilities and professionalism.

Not to put too fine a point on it.

Usability

Throughout the transition period, your users would have to cope with two competing layouts and two conflicting navigation structures. This would double their cognitive load in trying to keep track of where everything is, and would cause confusion about how the two halves correspond to one another.

(Looking at your before and after screenshots, it's totally unclear to me which links are intended to correspond to each other in each layout; this would be confusing even if you weren't planning to change the structure of the application along with the redesign.)

The problem will be exacerbated by the fact that things will keep moving around on them as you gradually transition from one framework to the next; it's unlikely you'd be able to document the current state of the system during the transition period, or that users would be able (or willing) to keep up with it even if you were.

change tolerance among our users is low

...so it's maybe not a great idea to subject them to months of ongoing, gradual but radical change.

Product Coherence

But it's even worse than that, because you're also planning to

redesign layout and navigation and not have to worry about backward compatibility.

...which means that the navigation structures will be in conflict; sections which are to be removed from the old design will be inaccessible from pages which have the new design, and vice-versa. The user will have to remember things like "ok, to get back to this old feature from this new page I have to click one of the nav links that I remember happens to point back to the old design, so I can get to the old navbar which links to the thing I actually want to get to. Oh, wait, I guess they updated that page now. How do I get back to the old design? Where am I?"

Or alternatively, you'll have to preserve and maintain the entire "old" application throughout the transition, just so you have a reliable fallback for the missing parts of the incomplete "new" application. This would be effectively the same as just redesigning the whole new product behind the scenes and cutting over on launch day, except much more difficult because you'll have to support both in public throughout the transition.

But you can't do that, either,

because of the extensive database redesign that's involved in this project... it would be impossible (or at least undesirable) to maintain both at the same time

Not worrying about backward compatibility is one thing -- you're proposing not worrying about current compatibility. Right now your users have a product they can use. While they wait for you to finish your redesign, they'll be stuck having to work with two halves of two different products.

Professionalism

We don't have time/resources to simply stop and redesign the app all at once

That may be true, but it's probably not a good idea to expose that fact to your users quite so blatantly.

Redesigning only part of your application clearly sends the message "we lack the capability to do this job properly, so please just bear with us while we muddle through."

No need to belabor this point further, I think.

So.... Instead of that...

It is probably not a great idea to redesign the product's appearance, and its functionality, and its navigation structure, while simultaneously transitioning from one front-end framework to another, as well as redesigning the database structure -- everything, in other words -- in public, with live data coming from both sides, while trying to keep everything in synch.

That's, like, a totally full Risk Factor Bingo card, even if you set aside the UX factors this answer is putatively about.

You need to separate these processes, for your own safety and sanity, as well as that of your users. Don't try to do everything at once; you'll fail.

If you need to change frameworks, I'd suggest completing that transition first, without considering any changes to functionality, layout, or structure. This will tend to make the code transition much quicker and smoother than if you're trying to make other changes at the same time. (It'll also have the incidental benefit of letting your devs get a handle on how React works before they have to dig in on the "real" new design; they'll be doing their learning on the version you plan to throw away, instead of on the code you'll be living with long term.)

Some database structure changes probably go along with that by necessity, but keep these as minimal as possible.

Once you have a solid footing from a technological standpoint, then it's time to start thinking about redesign and structural changes.

Especially with a change-resistant audience, I like to do this in two separate stages:

  1. Cosmetic changes. If these are major, do them all at once. Rock that new look-and-feel, move the layout around like mad, but keep all the functionality and the navigation hierarchy exactly the same, so the user doesn't feel lost; it's the same product, it just looks prettier. This is what will be perceived by users as the real redesign, even though it's functionally identical to what was there before.
  2. Functional changes, incrementally. Restructure your site map as needed, change the functionality that needs changes, but do these gradually and incrementally. This is where the real change happens, but it generally won't be perceived by users as a "redesign" because it all looks the same -- bits and pieces of it just work better every time you do an update. Doing this incrementally means you have the opportunity to get user feedback as you go, and back out mistakes before you've committed too heavily to them. It also mitigates the change resistance on the part of the user, because you're not changing everything around on them, you're just improving bits and pieces.
 
 
0
 
vote

Если старые разделы недоступны, когда новые разделы выкатываются, то поставьте «наклейку» на новые разделы, которые дает краткое объяснение и ссылку на более подробное объяснение.

Новый стикер

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

Когда появляются больше новых секций, чем старые разделы, возьмите «наклейку» с новых разделов и поставьте «наклейку» на старые разделы, которые указывают что-то вроде «Медведь с нами, как мы обновляем остальную часть сайта «.


Однако , идеальная ситуация - Дайте своим пользователям возможность обновить к новому дизайну или, по крайней мере, облегчить их в него. Различные люди имеют разные допуски, поэтому как старые, так и новые конструкции, доступные одновременно, являются оптимальными.

Чтобы сделать это, по умолчанию по умолчанию по умолчанию для старого дизайна и поставить «наклейку», которая предназначена для пользователей, чтобы попробовать новый дизайн на старых разделах, которые имеют новый дизайн.

.

Тогда, на новом дизайне, попросите пользователей, если они хотят загрузить новый дизайн по умолчанию по умолчанию.

Новый дизайн, с разрешением всплывающее окно« SRC = »HTTPS: // i.stack.imgur.com/jvme6.png

Как только пользователь выбирает «Да» или «Нет», вам больше не нужно представлять ее наклейку «Предварительный просмотр».

Делайте это до тех пор, пока весь сайт не переработан, а затем разверните новый дизайн как обновление.

 

If the Old Sections are not available when New Sections are rolled out then put a "sticker" on the New Sections that gives a brief explanation and a link to a more detailed explanation.

New look sticker

I suggest acknowledging the mental effort the user has to make during the change and particularly the transition period and why you think it's worth it.

When there are more New Sections than Old Sections take the "sticker" off the New Sections and put a "sticker" on the Old Sections that state something like "Bear with us as we update the rest of the site".


However, the ideal situation is to give your users the option to upgrade to the new design, or at least ease them into it. Different people have different tolerances so having both old and new designs available at the same time is optimal.

To do so, default to the old design and put a "sticker" that entices users to try out the new design on the Old Sections that have a new design available.

Old design with "sticker"

.

Then, on the new design, ask the users if they wish to load the new design by default when available.

New design, with permission popup

Once a user chooses "Yes" or "No" you no longer need to present her the "Preview" sticker.

Do this until the entire site is redesigned, then roll out the new design as an upgrade.

 
 
   
   

Связанный проблема

16  Должны ли заголовки всегда использовать один и тот же шрифт, что и тело?  ( Should headings always use the same font as the body ) 
Я работаю над некоторыми из макетов для пользовательского справочника и прямо сейчас, моя главная проблема - это шрифты. Я пытаюсь решить, использовать ли тот...

2  Топ бар против нижней панели для предложения по электронной почте  ( Top bar versus bottom bar for email subscription offer ) 
сайты иногда используют бар, чтобы пригласить читателей подписаться на их список рассылки. По моему опыту, большинство сайтов, которые это сделают, выбирают...

16  Как должны реагировать горизонтальные номера приборных панелей на отзывчивой странице?  ( How should horizontal dashboard numbers react on a responsive page ) 
У меня есть набор значений приборной панели на липкой горизонтальной панели на верхней части интерфейса UI. Эти цифры являются ценностями продаж, поэтому они ...

0  Какого роста слишком высока для фиксированного заголовка?  ( How tall is too tall for a fixed header ) 
Я недавно включил фиксированный заголовок на моем сайте и очень полезен в сохранении поиска и важных ссылок, доступных в любое время. Но моя забота это может ...

1  Какое наилучшее использование иконок в заголовке? (Иконки заменяют бесплатный текст)  ( What is the best use of icons in the header icons replacing free text ) 
Как лучше всего использовать значки в заголовке? В моем приложении я использую ряд значков для простых функций, таких как «Найти друзей». «Задайте вопрос» и т...

0  Несколько логотипов в заголовке с длинной навигацией  ( Multiple logos in header with long navigation ) 
У меня сейчас есть следующий заголовок: Общая идея здесь у нас есть основной логотип сайта, но поскольку мы предлагаем этот сайт партнерам компании, чтобы ...

8  Используются ли люди, чтобы увидеть «мою корзину» в заголовке?  ( Are people used to seeing a my cart link in the header ) 
Я разработал платформу электронной коммерции, где пользователи смогут покупать приложения с рынка. Я думал о размещении ссылок на «мою корзину» в ряде мест,...

6  Плюсы / минусы размещения входа в систему / аккаунт в соответствии с основным навигащим баром?  ( Pros cons of placing login account in line with the main nav bar ) 
В настоящее время наш навигационный заголовок в основном левая сторона и центральная страница, аккаунт находится в правом верхнем углу. Предлагаемый дизайн ...

3  Должен ли всегда быть заголовка и нижний колонтитул на сайте?  ( Should there always be a header and footer on a website ) 
Странный вопрос, возможно, я размышлял над идеей не использовать какой-либо нижний колонтитул вообще для приложения веб-сайта (не отзывчивый). Я думал о иде...

2  Заголовок IMG с цветным наложением или тенью на элементах?  ( Header img with color overlay or shadow on elements ) 
Я работаю над веб-приложением, и этот вопрос пришел к моему разуму. Я пытался осмотреться, но нашел много ресурсов из обоих подходов. Так что здесь я, пытаясь...

2  Размещение заголовка в мобильных приложениях  ( Title placement in mobile apps ) 
Какая лучшая практика для размещения названий страницы в мобильном разработке? в jquerymobile Это выглядит как заголовок Это отличное размещение , однако, ...

17  Это сайт с фиксированным заголовком хорошо для конечных пользователей веб-сайта Web2.0?  ( Is a website with a fixed header good for end users of a web2 0 website ) 
Фиксированный заголовок - это заголовок, который всегда виден пользователям, даже пользователю прокручиваются. Он использует фиксированную позицию в CSS. Та...

1  Какой лучший способ выравнивать заголовок и содержимое сайта  ( What is the best way to align header contents of a website ) 
Я работаю над веб-сайтом электронной коммерции, который состоит из страницы посадки, страницы поиска продукта и дизайна страницы деталей. Я поражен дизайн выр...

1  Ящик навигации Android без заголовка профиля  ( Android navigation drawer without a profile header ) 
Я реализую навигационный ящик в моем приложении, но проблема в том, что мое приложение не имеет ничего общего с профилями пользователя. Это заставляет меня за...

2  Свернутый заголовок / мега-меню  ( Collapsing header mega menu ) 
У меня есть веб-сайт с мега-меню. На главной странице мы ищем максимальное воздействие категорий веб-сайта (и мы можем пощадить комнату), а внутренние страниц...

5  Как указать нажатие на заголовок для получения дополнительной информации  ( How to indicate to click on title for more information ) 
Im Проектируя приложение и у меня проблемы с указанием пользователя, чтобы нажать на имя бизнеса («Candys» в этом случае) для получения дополнительной информа...

2  Интранет Статическое меню: ниже или выше страницы баннера?  ( Intranet static menu below or above page banner ) 
Я в настоящее время работаю над проектом для переработки интрасети большой организации. В настоящее время команда проекта обсуждает, должен ли на сайте Stati...

11  Смешивание полной ширины страницы NAVBAR с телом 960px  ( Mixing full page width navbar with a 960px body ) 
Есть ли когда-либо случайный случай для смешивания полной шириной верхней навигационной панели (то называя содержание навигационного батарея также является по...

2  Логотип сайта: включить TLD или нет?  ( Website logo include the tld or not ) 
Если логотип сайта включает в себя TLD ".NET"? Фон в мой конкретный случай: Я в процессе перепроектирования / перезарядки веб-сайта, который включает в ...

0  Это нормально не размещать заголовки на страницах?  ( Is it ok not to place headers on pages ) 
Мне нужен заголовок на вершине каждой страницы, у меня есть или является выдающимся указанием категории в боковой панели достаточно? Я продолжаю прыгать впере...

1  Многослойные заголовки в iOS  ( Multiline headers in ios ) 
Я проектирую приложение iOS с Q и AMP; раздел, где каждый вопрос является его собственной страницей. Не каждый вопрос удобно подходит внутри заголовка. Долж...

0  Введение на заголовок  ( Introduction on a header ) 
Я хотел бы знать, если это или не является хорошей практикой, чтобы поставить вступление в поясницу на каждой странице моего сайта на заголовке. Содержание мо...

2  Название заголовка столбца  ( Column header name suggestions ) 
У меня есть столбец в таблице с каждой ячейкой, являющейся тумблером (включение / выключение), какой бы подходящий заголовок для столбца? Прямо сейчас я тольк...

2  2 различных формы сортировки рядом друг с другом  ( 2 different sort forms next to each other ) 
прямо сейчас, на моем сайте TINDIE у меня есть 2 сортировки рядом друг с другом (один для сортировки продуктов Цена & AMP; популярность, другая для сортиров...

1  Лучшие практики для навигации меню, позиционирующие в отзывчивом заголовке?  ( Best practices for navigation menu positioning in a responsive header ) 
Предполагая, что у вас есть адаптивный заголовок, который всегда занимает всю ширину в области просмотра (например, один в https://mailchimp.com ), есть ли...

Связанный проблема

16  Должны ли заголовки всегда использовать один и тот же шрифт, что и тело? 
2  Топ бар против нижней панели для предложения по электронной почте 
16  Как должны реагировать горизонтальные номера приборных панелей на отзывчивой странице? 
0  Какого роста слишком высока для фиксированного заголовка? 
1  Какое наилучшее использование иконок в заголовке? (Иконки заменяют бесплатный текст) 
0  Несколько логотипов в заголовке с длинной навигацией 
8  Используются ли люди, чтобы увидеть «мою корзину» в заголовке? 
6  Плюсы / минусы размещения входа в систему / аккаунт в соответствии с основным навигащим баром? 
3  Должен ли всегда быть заголовка и нижний колонтитул на сайте? 
2  Заголовок IMG с цветным наложением или тенью на элементах? 
2  Размещение заголовка в мобильных приложениях 
17  Это сайт с фиксированным заголовком хорошо для конечных пользователей веб-сайта Web2.0? 
1  Какой лучший способ выравнивать заголовок и содержимое сайта 
1  Ящик навигации Android без заголовка профиля 
2  Свернутый заголовок / мега-меню 
5  Как указать нажатие на заголовок для получения дополнительной информации 
2  Интранет Статическое меню: ниже или выше страницы баннера? 
11  Смешивание полной ширины страницы NAVBAR с телом 960px 
2  Логотип сайта: включить TLD или нет? 
0  Это нормально не размещать заголовки на страницах? 
1  Многослойные заголовки в iOS 
0  Введение на заголовок 
2  Название заголовка столбца 
2  2 различных формы сортировки рядом друг с другом 
1  Лучшие практики для навигации меню, позиционирующие в отзывчивом заголовке?