I am working on my website where I sell concert tickets.
I am working on designing the part of the website where I generate tickets based on seat and rows available.
After some thinking and drawing I have to the conclusion that this design would be best for my problem.
I was wondering is this poor design or are there any improvements that I can make?
Thank you
I wouldn't expect to have a table of unbooked seats. A table of bookings seems more logical. Your concerts table looks questionable if you expect to have a series of dates for the same concert.
Perhaps you should first sketch out the key functions of your site as User Stories or Use Cases and list out the required attributes for each. That could give you a better set of requirements for your database design, e.g. what customer attributes; what about seat attributes such as restricted view, standing places or accessible places for the disabled.
I have a classic lotus notes form with 1800 fields and 7 tab,
Will the performance improvement if i split the form in 7 different form and then bind to the xpages
or
if i directly bind the form to the xpages will there be any performance impact?
thanks
That's a "try that with your RDBMS" type of situation.
Splitting forms will not help you, XPages doesn't care too much about how many data sources are used if the number of bindings is high (and you have a ratio of still > 200 for many forms) --- and you actually don't bind to a form, you bind to a document. The form is only a "design time convenience".
Making some wild guesses I would presume that a lot of the fields are repeating fields (like LineItem_1 LineItem_2 LineItem_3 ) instead of multi-value fields.
Moving forward you need to make a basic choice:
Is your data format fixed since all views, reports, import/export routines etc. rely on them .or. can you refactor the data model (based on your question I would presume the former).
If it is fixed I would look to encapsulate the document into a managed bean that provides collections of data for the repeating sets of fields and repeat controls to show the number of entries you actually need (The classic way would be to have different hide whens in every cell of the table hosting the fields). This way you have much less bindings to look after.
A very basic idea how to have a dynamic table can be found in Excercise 23 of the IBM XPages tutorial
Disclaimer: Tim Clark and I wrote that.
You also might consider using only that parts of the document the specific user needs that moment.
For this kind of situation, As of my concern, You have a form with seven tabs and 1800 fields. But it is too complex. But however we split a form into seven, each form will have 260 fields. now also code will become complex.
But my suggestion is that you can dynamically change the binding data in xpages. If you feel very complex to redesign the form then you follow the above idea. Otherwise change the design and make a nice look-up in xpages.
Dose the ListBox in MFC framework have limited item length? If so, what is the limit?
There is a limit. For an owner draw one it's probably related to the limits of the GDI coordinate system.
However, long before you reach the ListBox limit, you reach the limit of good UI. Wide horizontally scrollable listboxes aren't easy to use. If you have very wide data to expose, consider another UI abstraction, like a tree or multicolumn list, and consider what kind of data your user actually needs to see.
Martyn
I'm working on a pretty basic web app (not much more than CRUD stuff). However, the requirements call for a bunch of data to be displayed with each item in the search results - IDs, dates, email addresses, long descriptions... too much to fit neatly into a simple grid, and too dissimilar to make them flow together (like the natural language example from this article.)
Is there a design pattern for attractively displaying many descriptive fields with each search result?
(Please don't tell me to just remove some fields from the results; that's not an option for this project.)
Obviously there are many ways you can handle this, and to a degree it's a factor of your information design abilities and preferences.
Natural Data Groupings
What I would do is try to organize your data into a small number of "buckets." You state that the data are too dissimilar to be arranged into a sentence, but it's likely you can create a few logical groups. Since we can't see all your data, I'll guess that you have information about a person (email, name, ID?), about some sort of event (dates? type?), or maybe about some kind of object related to the person (orders? classes?). Whatever they are, some of the data will be more closely related to each other than others.
Designing in Chunks
Take each loose "bucket" and design a kind of "plate" -- a grouping just for the information in that bucket. The design problem within this constrained chunk is easier to tackle: maybe it's a little table-like layout, maybe it's something non-tabular, like the stackoverflow user "nameplate". Maybe long textual data have their own plates, or maybe they're grouped into a single plate, but with a preview/detail click-for-more arrangement.
Using a Grid
Now that you have a small number of "plates," go back to a grid-like approach for your overall search result row design. Arrange the plates as units within the row, and be sure to keep them aligned. Following an overall grid (HTML table or otherwise) for the plates will avoid an "information soup" problem. You'll have clean columns that scan well, and a readable, natural information hierarchy. The natural language example you cite would indeed be difficult to parse if it were one of many rows displayed in a search results grid.
Consistency
Be sure to use a common "design vocabulary" when you're working on the chunks -- consistent styling of labels, consistent spacing... so when everything's displayed, despite the bulk of information, it all feels like it's part of the same family.
It's an interesting design exercise. Many comps, lots of iteration, and some brainstorming should get you where you need to be.
It probably depends on the content you're displaying. Look at the StackOverflow layout for this question. It has Votes, Title, Description, Tags, Author, etc. The content wouldn't work well in a grid for sure, nor does it flow nicely on it's own.
I think it's time to get creative ;)
No one ever thinks about what this is going to look like on their screen, do they?
One thing you can do is truncate the displayed text, and then display the expanded version in a tooltip on hover, or after the user clicks on it.
For example, display only the two-letter state abbreviation but show the full state name on hover.
Or, to save even more space, only display the state abbreviation, and put the entire address in the tooltip.
For long descriptions, you can display only the first few characters, followed by an ellipsis or the word "More". Then, show the full text either on hover or on click.
One disadvantage of the hover approach is that you can't sort the column on that text. There's nothing for the user to click to request the sort.
I thought I would ask the SO community on helping me with a project that I am currently working on. I need to model the price for a widget in a market situation. The price for the widget should be a result from the current supply and demand. Users will be able to buy and sell the widget at the fixed price. As users buy the widget the demand will go up along with the price. Conversely as users sell the widget the supply will go up and the price will go down. The quantity and current price of the widget will be stored in a database along with the total number of buys and sells for the widget.
Protrade.com has an excellent example of buying and trading widgets (players and teams), I would want to model my system in a similar fashion.
Is there any good programming libraries that will accurately model a market based on supply and demand?
Unfortunately I do not know of any libraries, but perhaps you can tap into Excel's statistics functions.
My opinion follows.
This is why economics is so boring, everything is supply/demand.
Something along the lines of the following should work as a start:
ListPrice = (Cost + Profit) * (demand/supply * economic-factor)
where economic-factor is some determined constant.
If you have some historical data, eg daily supply/demand ratio's you could factor it in, perhaps using some time-based scale.