Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The system that I am working on is an Intranet System only accessible within the company network to our staff. This is a primary system for storing data of all our customers. The system is entirely web based. There is a lot of data to be captured and held for each customer. At the moment opening up a customer record brings up all the information is input boxes, etc so that users can change them and click on the save button to update. There are about 40 to 50 pages organised with fields all over the page. There is a single top level navigation bar with a side navigation bar as well.
We have decided to work on the design and layout of the pages. The first step will be to create a Detail View and an Edit View. At the moment there is no Detail View, everything is shown within the same Edit fields.
Do you have any good ideas on improving usability on an intranet database system (web based)
It's a big question. The approach you mentioned is very much focused on the details when you might be better served figuring out the high-level design first. It sounds like you have a lot of data and might be overloading your users.
I would recommend that you do the following:
Ask your users. They live right down the hall, so this is easier for you. Ask them what kinds of things they go to the intranet for right now. (You can ask them to talk about hypothetical situations, but that's a different technique, and yields speculative data.) Ask if you can watch them use the intranet.
Aggregate their feedback and try to see patterns in it. Can you group data according to some logical classification? Is it better for you to provide a database-style search interface? What about both -- they're not mutually exclusive?
Look for examples. Look at websites that work for you: Stack Overflow? Amazon? Netflix? Whatever it is. What can you learn from how they organize and present information?
Mock up a simple prototype. And when I say 'simple' it could just be markers and sticky notes on a whiteboard. Use this low-fidelity prototype with a few users and see if they can figure it out. Don't "help", see what they make of it -- see if they can find what they're looking for.
Iterate. Do steps 1-4 over and over as you approach a design.
Good luck! This is a real challenge, but if you make a system that works well you will save your company a huge amount of wasted time; and time is money.
Well, this is really about "web user interface design" and the fact that you are on a company intranet really doesn't matter too much one way or another, except for the fact that you can assume users know certain things about your company already.
As for good interface design via a web interface, you may want to check out the other SO posts below:
Book Recommendations
User Interface Design
other search results
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm looking to create a rather content-heavy (but low budgeted) website that is going to have a lot of different sections.
The post important requirement is that it be easy to user for the administrator who won't be very tech-savvy. What I'm looking for is to minimize them coming back to me whenever they want something on the website done (i.e. adding a contact form or something like that).
The website is, for the most part, going to be a simply two level design. Each 'section' (i.e. link the navbar) is either going to be a standalone page or a page that lists other pages in a section (these pages are what constitutes the second tier).
To give an example, the top tier may be:
Home | News | Events | Volunteer | About
Home and About will be standalone pages. News will list all sorted news items. Events will list events in a potentially arbitrary order (i.e. user-weighted). Volunteer will be a form that will send an email to the 'volunteer manager'.
These volunteer-type, data-entry forms are going to be used in multiple places throughout the website and I'd like it to be rather simple for users to create these forms and get the data back from them (either through email or a backend interface).Furthermore, a section should be capable of having both forms and normal pages.
I don't know how well written this post is but that's the gist of it. Normally I'd choose Drupal but I'm not sure the person managing the website is going to be able to use it without having to come back to me constantly (although I might revert to it depending on what's available).
I was wondering what other recommendations you guys have for a system that's easy and intuitive but powerful enough to handle what I listed above.
I should note that while I'd prefer it to be a PHP-based CMS any open-source CMS should suffice for this project.
I did a usability study of different CMS systems in college and I'd like to share with you some of my findings:
After evaluating three systems, an average was taken of their usability problem severity ratings for each category for each system (0 being no problem at all, 5 being severe usability problems). Drupal had an average rating of 1.7, Joomla had an average rating of 1.5, and PHP-Fusion had an average rating of 1.2.
My recommendation for beginners is PHP-Fusion since the interface is very easy to learn. Intermediate to advanced users should use Drupal for its huge collection of features and extensions. But if one wants a middle ground between simple and feature-rich, Joomla would be the best system for that purpose.
If you're interested in the full study, I can email it to you.
My initial thought would be Drupal but you have already mentioned it as probably being too complicated.
I know most web developers will flinch at event the mention of this, but have you considered Wordpress? Some of the custom themes are pretty sophisticated and mimic a CMS pretty well. The advantage of wordpress is that it would be very easy to maintain for someone who has no knowledge of php.
I'd still say go with Drupal; just carefully create a role for the main user of the site and don't give them full admin access. That way they are shielded from the full complexity (and from screwing things up).
Joomla is what i would suggest.
Wordpress sounds like the best idea. It's free open source and PHP.
Check out Contact form 7 for your contact forms, as they are very customisable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I wonder if there is any practice when designing a forum. I want to design a couple of forums. yes there are two different types of forum at least. one is for a selective members and another is open for any public members.
In the forum, the member can initiate a thread, then other members can respond to it.
So I have this rough idea for the structure of this type of forums.
I'd name the forum table as 'strings' table. this is the structure I can think of,
str_id for the auto increment id
str_tilte for title of the thread
str_content for content/ text of the thread
str_follow for you to choose whether you want to follow this thread or not
str_approved for the admin to approve or reject the thread
parent_id*1
mem_id member id who initiates the thread or who responds to the op
cat_id*2
str_created
str_updated
*1 eg. if the data injection is an op thread then the parent id is itself, if the injection is a response to the op, its parent id is the str_id of the op.
*2 this column is to store the category id of the current data injection. if the injection is a selective forum then it is 1, if the injection is public forum then it is 2.
not sure if I am on the best track, but please let me know if you have any better ideas.
thanks.
edit:
thanks for some reply and suggestions that using phpbb.
just had a look and downloaded phpbb. it is 101% sure that I won't go for it. it is a whole programme like Wordpress or any other PHP frameworks (like Zend). I have an independent framework running this website, so I don't want to run another programme/ framework to mess up the site's backend structure, etc.
if I the site is only a pure forum website, then maybe I would be considering phpbb. but the forum is just a sub feature of a holistic website in my current project.
Don't start with a table, start with a conceptual ER Diagram of your base entities, forums, threads, replies,members, keywords, categories etc. and express the relationships first.Then get into logical design mode and define the tables needed to implement the functionality. As suggested have a peek at the way phpBB tables are organized.
I like to do my first diagram on a printing whiteboard or on paper then move to a diagramming tool for logical design.
I think there's still some room for a 'better' forum, so good luck.
Greetings.
As i previously recommended in comments to your question.
I strongly recommend you to set up local installations of other open source database driven forums in your machine, in order for you to have a strong idea and base of what other developers did when they develop such forum applications, not just looking at the database tables but also to the code, organization and design of the forum. I think it proof it self very useful to open your eyes to possibilities for your own forum application
A few examples of database driven forums:
phpBB
Simple Machines Forum
XMB Forum
I usually say the best way to learn is trial and error but let me also point out. Even this forum application your creating, its just for small and private use for your websites.
You should consider that your forum application one day may become popular and you might desire to turn it public like these previous ones mentioned, or you just want to add some new features.
In this case i suggest you plan your Code and Database Architecture very well, planning ahead for future upgrades.
Also you should take MikeAinOz advice very seriously in his answer and start by
Conceptual ER Diagram of your base
entities, forums, threads,
replies,members, keywords, categories
etc. and express the relationships
first.Then get into logical design
mode and define the tables needed to
implement the functionality
Thats the best answer to this kind of question i ever seen.
Regards & Good Luck.
My thoughts...
str_follow shouldn't be in this table. It should have its own table that links members to subscribed threads.
I'd recommend having parent_id null if its a top level thread, it makes more sense.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 11 months ago.
Improve this question
I create custom CMS sites and then go ahead for the backend/admin side. Is there any tool out there to automatically create admin side of my sites, for example, based on table relationships or whatever customization we may put in place.
PHPMaker seems to claim something like what I ask for but I have not used it. Any tool out there to auto-create admin side or PHPMaker is up to the point?
Did you mean something like this?
http://www.phpgrid.com/grid/
It visualizes all of the data and allows for editing, paging, sorting, kinda like MS Excell, or asp.NET gridview's.
If you're looking for something that automatically reads your database structure and deduces everything you might possibly want to do, and provides buttons for it - no such thing exists, well, not until software really begins to program itself.
phpMyAdmin :oP ?
There is nothing out there that can automate an admin control panel sufficiently. There are too many things that your data can mean. An INT could be an integer, or it could be a code where each value 0-9 represents some different value. What about other tables which are not visible to public eye, like the users database and the logs? What do you do with those? If you want a control panel that's worth two cents, you'll build it yourself. One of the main reasons for admins to stop using a CMS is that the admin panel is incomplete or confusing.
Symfony has such an admin generator:
http://www.symfony-project.org/screencast/admin-generator
You need a code generator that can read your DB structure and then generate your back-end based on a few additional definitions you may supply.
Like #animuson said, "there are too many things that your data can mean". However, only a limited subset of those "many things" is relevant to you, so you can associate a well-defined meaning (from that subset) to a specific field or data set. The code generator will then act on that specification and generate the correct back-end code.
Model-driven development will help you here because a model of, let's say, a table column, may contain only the definitions that are needed to properly understand the meaning of that column.
There are tools on the market for this, open-source and commercial, that will help you define your models and build your code generators.
Of course, there is an additional cost of building and maintaining your code generator, but once you have it you start reaping the benefits in time savings and less errors.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have a "web application" which has been developed over the past 7 months. The problem is, it was not really documented. The requirements consisted of a small bulleted list from the initial meeting 7 months ago (it's more of a "goals" statement than software requirements). It has collected a number of features which stemmed from small verbal or chat discussions.
The developer is leaving very soon. He wrote the entire thing himself and he knows all of the quirks and underlying rules to each page, but nobody else really knows much more than the user interface side of it; which of course is the easy part, as it's made to be intuitive to the user. But if someone needs to repair or add a feature to it, the entire thing is a black box. The code has some minimal comments, and of course the good thing about web applications is that the address bar points you in the right direction towards fixing a problem or upgrading a page.
But how should the developer go about documenting this web application? He is a bit lost as far as where to begin. As developers, how do you completely document your web applications for other developers, maintainers, and administrative-level users? What approach do you use, where do you start, what software do you use, do you have a template?
An idea of magnitude: it uses PHP, MySQL and jQuery. It has about 20-30 main (frontend) files, along with about 15 included files and a couple folders of some assets -- so overall it's a pretty small application. It interfaces with 7 MySQL tables, each one well-named, so I think the database end is pretty self-explanatory. There is a config.inc.php file with definitions of consts like the MySQL user details, some from/to emails, and URLs which PHP uses to insert into emails and pages (relative and absolute paths, basiecally). There is some AJAX via jQuery.
Please comment if there is any other information that would help you help me and I will be glad to edit it in.
The developer leaves on Friday. However he can dedicate most of his 24 remaining hours to this documentation task. So, yeah, things are bleak but 24 hours is quite a bit... right? :-\
I would start by listing the main features that the application currently implements (update the initial bullet points).
Then, for each bullet point, write down the main requirements associated with that bullet point.
For each requirement, write down:
Anything quirky about that particular requirement
Where in the code that requirement is implemented (which php, inc files, tables)
This will give you something of a traceability hierarchy
Feature => Requirement => Implementation
It will also provide a good framework to jostle memories and write down gotcha's.
Then, comment each php and inc page.
Start with a header that outlines the purpose and which requirement(s) from the previous list are satisfied (reverse traceability from code to requirement).
Go through each php/inc file and comment the major actions/decisions/loops indicating what they are trying to accomplish and any design considerations that are assumed (e.g. "input is assumed to have been validated in the previous step").
When commenting the source code, you may want to use a tool such as PHPDoc so that you can generate documentation out of the comments.
One approach could be to arrange a series of hand over meetings. In these the developer would have to explain the code for each section.
He could write some notes in preparation for these, but having the other developers take minutes as well might help them understand the code. Also these meetings would be an opportunity to ask questions about aspects that aren't clear.
Don't try to do the whole site in one go. Break it down into smaller chunks grouped somehow - by function or by area. This means that your other developers aren't bombarded with too much information in one go, the original developer can concentrate on one area at time and you have a chance to follow up after the meeting.
Even if nothing "sticks" straight away there will be some documentation and some familiarity with the site when you revisit it later.
Another approach could be for the developer to give a series of short presentations on the site and how it was built. This might prompt him to remember why he took the approaches he did. This is invaluable when looking at code. If you know what problem it was trying to solve it's a lot easier to understand.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I’m working on a project and have developed the high level user requirements for what the system must do. This project is a php web application built on the CodeIgniter framework. Now I’m trying to take those requirements and break them down further into controllers/actions. What is the best way to do this?
I was thinking of creating a word document with a table that would have four columns. Column one would be the the name of the controller, column two would have the actions, column three would have the name of the view that is specific to the action, and the fourth column would show which users had access to that action. Does this sound like a good idea?
I like the interface first approach to building an application, but realistically, I need to know what views I need before I can create a prototype interface.
Could anyone help me out with how to plan the app and any documentation that might help?
Your breakdown is a good idea, but it's really the second step.
here's what I'd do:
take your requirements, and turn them into a series of scenarios ("use cases", "user stories").
Pick one, and sketch, like on paper, the basics of the user interface you'd want if you were to have the Good Code Fairy deliver the perfect system to you.
separately go through the scenario, and underline all the nouns in the story; those are probably domain objects. Underline all the verbs in a different color. Each verb is a method of one of those domain objects. (In fact the domain object will be the object of the verb. Cool, huh?)
Figure out how you would implement that user interface using those domain objects.
Build it
Show it to your customer, who will invariably say "I like it but"
Put the changes and things you learned inot your requirements, and repeat until the check clears.
Peter Coad wrote what I still think is really the best beginners book on this: Java Design: Building Better Apps and Applets. It's oriented to Java, but the design part is universal.
Your domain objects are the model, the display of your data is (roughly speaking) the view, and the code attached to actions is the controller.
On Use Cases
The "right way" to do use cases or user stories is subject to immense discussion and religious warfare. There are zillions of options, from Cockburn's somewhat complex form, to notes scribbled on index cards.
For the kind of application you're describing, I do two things: I try to keep them to 25 words or less, and I think about the SMART acronym.
Twenty-five words or less helps keep them small. Doing a few small stories is preferable to spending weeks on a big one.
SMART stands for "Specific, Measurable, Agreement with Responsibilities and Tests." (Or at least that's how I interpret it. There are other versions.)
Specific, you have to be comfortable you know what's being asked.
Measurable, you have to have some way of testing or some kind of statement of what will be acceptable
Agreement, because it needs to be something you and the customer can both agree satisfies a need — in other words, the "meeting of minds" of a contract
with Responsibilities, you have to know what you're being given, what the customer or user is responsible for providing, and what you are
and Tests, in other words, you should have an effective procedure that gives you the answer "it is acceptable" or "it's not acceptable."
The form I use has the pattern
User in a particular role
does something
resulting in some benefit
So, in your example, I would write
Administrator (who?)
lists all FAQs (does what?)
to review them for updates. (why?)
The "resulting in some benefit" part is something I emphasize and a lot of other people don't, or don't even mention. It helps a lot later if you need to prioritize them.
The "test" part is a description of an acceptance test: you're answering the question "Is this done?" So the acceptance test might be
A logged in administrator selects "list FAQ". All known FAQs are listed in correct format.
Ideally, you'd set this up so some tool, like expect or a gui test tool, can run this automatically, but especially in a small projects you may end up testing by hand. You want automated testing, because as you build the system, you want to do regression tests; that is, you want to repeat your tests to make sure nothing has been broken by a later change.
What you do is you work user-centered.
You make rough mockups of the screens (use Balsamiq or something), and show them to your client/stakeholder, and walk them through it (as if they were using it). Get them to agree.
Then you code the thing (I'm sure you can figure that part out)
Then you show to your client again (have them actually use it in detail), and agree on changes.
Now you finish it
Good luck!