Веб-страницы, которые просто очень наполняют
Приблизительное сопоставление строк не является хорошей идеей, так как неправильное совпадение приведет к аннулированию всего анализа. Если имена из каждого источника одинаковы каждый раз, то для меня лучше всего подходят и индексы построения. Это легко сделать в R:
Предположим, что у вас есть данные:
a<-data.frame(name=c('Ace','Bayes'),price=c(10,13))
b<-data.frame(name=c('Ace Co.','Bayes Inc.'),qty=c(9,99))
Создайте индекс имен для каждого источника один раз, возможно, используя pmatch и т. Д. В качестве отправной точки и затем проверять вручную.
a.idx<-data.frame(name=c('Ace','Bayes'),idx=c(1,2))
b.idx<-data.frame(name=c('Ace Co.','Bayes Inc.'), idx=c(1,2))
Затем для каждого слияния с использованием:
a.rich<-merge(a,a.idx,by="name")
b.rich<-merge(b,b.idx,by="name")
merge(a.rich,b.rich,by="idx")
Это даст нам:
idx name.x price name.y qty
1 1 Ace 10 Ace Co. 9
2 2 Bayes 13 Bayes Inc. 99
8 ответов
Нет никакого эксперта, который может дать Вам правило, которое работает во всех местах в любом случае. Я был известен в моей промышленности в течение многих лет для "легких" интерфейсов, и мы выиграли существенные торговые обороты для нее (а также 5 "Лучше всего в Классе" премии). У меня также были люди в моей компании, и за пределами него говорят мне - в течение многих лет - что они любят мою работу, но желают, чтобы я "подбодрил бы его" с большим количеством графики и таким. То, что всегда поражает меня, - то, как маленькие люди соединения видят между двумя.
Так... несколько эмпирических правил:
- страница А должна сделать один основной вещь.
- страница А может иметь несколько ссылок, связанных с главным
- Menuing, и связаться, расположение должно быть последовательным через страницы
- Более простой, лучше, чем более сложный
- , Страницы должны визуально обращаться и приглашать
- , Правило 4 более важно, чем правило 5.
, Например, мой продукт обеспечивает интерфейс, который позволяет людям определить классы и события, которые будут отображены в календаре. Я мог иметь одну страницу, которая позволяет Вам Обзор, Добавьте, Обновление, Удалите и Редактирование классы. Действительно, в некоторых более простых областях, я использовал gridview, чтобы позволить людям управлять всем в сетке. Однако классы имеют слишком много информации, чтобы сделать это и все еще следовать правилам выше.
Так,
- основная идея : "Вот список классов для этого местоположения"
- , ссылки состоят в том, "Добавьте Новый" показанный выше и направо от сетки, Изменения и Удалите, ссылки в каждой строке. Это последовательно через приложение.
- Menuing для системы в целом всегда через право/вершину. Ничто иное не появляется на странице класса/события за исключением стандартных элементов, характерных для всех страниц (логотип, заголовок, нижний колонтитул).
- сетка приятно разрабатывается, но нет никакой побочной графики (4,5,6)
Несколько последних вещей о UIs и графическом дизайне.
Первый, разработайте свое собственное видение и быть последовательными через страницы и приложения.
1124-секундный, не бойтесь простота .
Затем, при требовании совета от других имеют в виду, что Вы не хотите их совета - Вы хотите их впечатления: Вы хотите понять способ, которым они чувствуют интерфейс. Совет иногда хорош, но, как правило, на самом деле вреден. По моему опыту, все думают, что они - эксперт UI.
, Когда Вы, Ваша прихожая (или формальный) useability тестирование Вас должна обесценить почти весь совет о том, что "необходимо сделать , что выделяются больше". Как Вы будете видеть, это быстро станет "и это ", "и это ", "и другой ". Если Вы последуете этому совету, то Вы закончите с путаницей из-за первого правила Brittingham дизайна: , Если все не важно, чем ничто. (Там Вы идете: когда, объясняя, почему Вы не можете заставить кого-то выделиться больше, просто скажите им, что "это нарушает первое правило Brittingham дизайна!")
Hope это помогает!
Вы попадаете в точку. Используйте принцип KISS. (Сохраните Это Простым Глупый), я сделал это в прошлом также и мало того, что это делает для отвратительного UI, но и путающий относительно того, какие операции можно сделать на странице из-за наличия слишком большой функциональности. Я часто находил в тестировании этого, у меня не было достаточных проверок, чтобы видеть, мог ли пользователь выполнить определенную операцию на основе состояния данных.
достаточно легко в ASP.NET записать несколько страниц, которые делают простые задачи и затем связывают их вместе с Ответом. Перенаправление или Сервер. Передача. Теперь все, чего я пытаюсь достигнуть на любой данной странице, - то, что говорят спецификации дизайна. Таким образом, если моя страница является просто страницей результатов поиска, это - все, что я даю. Если пользователь хочет видеть детали объекта, который был возвращен в поиске, то я отправляю их в itemDetails.aspx страницу.
Вы повредили стену, которую большинство разработчиков программного обеспечения имеет, тот, который загораживал Ваш обзор на удобстве использования прежде. Много разработчиков действительно не думает об этом и пытается помочь им путем наполнения функциональности в одном окне, веб-странице или что бы то ни было.
вещь состоит в том, как только Вы начинаете разрабатывать программное обеспечение с точки зрения пользователя, т.е. помогать, несколько вещей начинают становиться ясными. Каждый - проблема обслуживания кода, тот код легко более managable, чтобы продолжить работать, если Вы не наполняете все в одном гигантском классе или безотносительно пародии, Вы делали. Другой само удобство использования, что Вы начинаете думать, как пользователь на самом деле использует Ваше приложение через графический интерфейс. Треть избегает требований или расползания границ проекта, где Вы прекращаете разрабатывать функциональность, в которой не нуждается пользователь.
Мы как пользователи хотим простоту частично, потому что мы не хотим проводить большую часть нашего времени, выкарабкиваясь плохой UI, когда мы можем получить нашу работу, сделанную быстрее с простым и гладким UI. Это делает его для нас разработчиками программного обеспечения правильный поступок, для продумывания дизайна на всех уровнях... это и , спецификации всегда лежат .
Определенно согласитесь: большинство попыток записи страниц/форм, которые действительно очень имеют, привело к
- ошибки и перезаписи. Проблемы происходят при хранении всех допустимых/синхронизирующих частей,
- избыточное управление ожиданий пользователей (" я ввел номер счета здесь и нажал "find person" там, но это дает сообщение об ошибке. Почему? "), когда эти два являются логически отдельными. Эти вопросы не могут возникнуть, если только допустимые опции видимы,
- проблемы Форматирования/расположения: На страницах ASP.NET пробуя к расположению независимые Пользовательские элементы управления оказываются кошмаром (" , Но мы действительно хотим все кнопки, вертикально выровненные! " в средствах управления отдельного пользователя. Удача с этим.)
я рассмотрел бы веб-страницы больше чем с одной функциональностью, только если целевая аудитория состоит из специалистов по проблемной области, т.е. людей, которым нужна большая функциональность на одной странице для лучшей производительности (думают ввод данных или финансовое программное обеспечение с большим количеством переменных).
Даже тогда, большую часть времени, это возможно, разделяют страницы на единые блоки.
- Никакой
- Да - меня
- я нашел, что золотая середина должна была использовать Masterpages и использование его способом, который был знаком IFrames. То, что у меня могла быть большая функциональность, объединенная хорошо вместе. Существует более интересный способ сделать это с WPF/Silverlight, названным Призма
Сумма функциональности на странице обычно не определяется Вами, но Вашим клиентом. Если потребительский спрос единственная страница для обновления приблизительно VeryComplexObject Вы, вероятно, закончите с aspx страницей, которая имеет значительное количество строк. Главная причина состоит в том, что у Вас просто есть много обработчиков событий для всех действий на странице.
, Сложна ли та страница, полностью ваше дело. Необходимо всегда пытаться сделать код - позади файла максимально простым и чистым. Некоторые предложения в том направлении:
- Перемещение весь бизнес-код к другому прикладному уровню.
- Использование
ObjectDataSourceдля обеспечения данных к средствам управления с привязкой к данным такой какListView,GridView,Repeater... Делегирование загрузки данных к специализированному объекту предотвращает много издержек в Вашем aspx.cs файле.
Другое предложение состоит в том, чтобы использовать пользовательские элементы управления для реализации частей страницы. Вы обычно только делали бы это, когда можно снова использовать пользовательский элемент управления, но он может также очень помочь, уменьшив сложность страницы (оба из кода - позади файла, а также aspx).
Иногда я думаю, что мы все виновны в упущении, кем случается так, что мы разрабатываем наши приложения для. Не всегда легко как разработчик быть в состоянии предпринять шаги назад и взглянуть на Ваше приложение, как пользователь мог бы сделать так. Поэтому сотрудник крупных компаний сотни людей, чтобы сделать это для них и они не всегда разбираются в нем.
Удобство использования является крупным предметом, но это - вызывающе что-то, что должны иметь в виду все разработчики. Мне потребовалось долгое время для изучения этого, но при занятии любой задачей разработки я всегда пытаюсь думать о том, как мои пользователи собираются взаимодействовать с тем, что я пишу. Это будет иметь значение ко всем уровням Вашей разработки.
я предложил бы читать , не Заставляют Меня Думать Steve Krug . Эта книга не возьмет Вас возраст для чтения, и она излагает некоторые фантастические мысли, которые могут помочь Вам разработать приложения, которые намного легче использовать и понять.
я всегда нахожу, что, как только я думал о пользователе, испытывают решения о том, что мои веб-страницы собираются сделать и как они собираются взаимодействовать, намного легче сделать.
Возможно, необходимо спросить людей, которые используют сайт. Или еще лучше, просто наблюдайте, что люди используют Ваш сайт. Я думаю, что это сказало бы Вам, если Ваш сайт разработан хорошо, или если необходимо изменить его.