I want to use the News system extension from Georg Ringer like this:
Multiple News Details & Lists All on one page
the Detail view on top of the "cards" of the List view should show the Detail of the item clicked on
The behavior seems like to allow multiple list but only 1 detail view
Detail View of "Services"
List View of "Services"
------ other stuff
Detail View of "Projects"
List View of "Projects"
------ other stuff
Detail View of "Sectors"
List View of "Sectors"
Has anyone experience with this?
I would change the list view to handle the first news entry with much more information. In Fluid you have access to all needed fields for displaying it like in detail view.
Then, you only need three list views on the page with your special template. No need for a detail view.
In general it's possible what you desire but you've to adjust the detail-view in the plugins statically to a special detail or you always will only be able to display one detail at a moment, no matter which category because news is like probably all TYPO3-extensions not programmed with the ability to transfer parameters for several plugins on a page at once.
Many years ago when extensions still have been programmed fundamentally different I had some similar desires related to other extensions and programmed something which transferred the parameters always related to each plugin on a page, so it was possible to regulate several plugins of the same type on a page separated. Today it will be harder probably to implement something like that.
What you can do is to look in the manual about the AJAX-posibilities of news. There might be still an option to fetch the detail for each of the categories separated, perhaps even on page-load already, but it will be a nifty setup which takes probably some time.
Related
Here's the issue, I build a special book reader/browser (For holy quran), my code behind loads the page and constructs how it should look. and then it should bind that look to a some kind of data-bindable custom control to view it properly. the problem is, the look differs from page to page, so I cannot bind to a certain control or wrap panel.
here's how it generally looks:
The decorative border top of the page is always there at any page, it indicates the part and chapter the viewer is in.
If you're starting a new chapter it have additional image under that decorative border or anywhere in the page (there can be multiple chapters in the same page) something like this
or this:
The normal text is not an issue, it's just a special font, however, I put each individual word in its own text block for reasons of user selection by word.
The issue here is, given the previous information, and knowing how random it is to place the decoration picture or the amount of words (text blocks) per page. how can I bind that to some kind of view to separate the view from the VM and Engine that builds the page.
my past solution was to actually build everything in the VM in a wrappanel built inside a scrollviewer having lots of textblocks and images according to the page. but that's naiive solution. I want to rebuild that in a more professional separated way. I also want to do this for Windows RT beside Windows phone so I need to reuse the code behind in a Portable class library.
I think all you need to do is slightly adjust your current design. So perhaps have a VM that represents the entire content, and that would have a Collection of say Pages or Sections. A second VM would represent the Page/Section, allowing you to create a property for the WrapPanel content (i.e. the words) and another property for the Header and or other things.
In the View you would have the scrollviewer and bind to the main VM collection. Then create another View or DataTemplate that represents the Page/Section.
You should be able to do this is a strict MVVM sense quite easily and it will be dynamic based on the content.
You could even cater for advanced scenarios where each section has a different template/view.
So basically I have made a storyboard based app which consists of table views and text. It is designed to help new programmers like a handbook. You have a table view which allows you to choose a language, a table view which allows you to choose a section (eg initialisation) a table view to choose a subject (e.g. integer) then a text view of how to go about this.
When it was reviewed, they said
Did not include iOS features. For example, your app was just largely
text table views. It would be appropriate to use native iOS buttons
and iOS features other than just web views, Push Notifications, or
sharing.
I feel like adding these things would degrade from the simplicity and educational purpose of the app. Also, I feel it might be more difficult to navigate if its all iOS button based. Also it might be more difficult to add things later.
So how would you go about adding these things to a table based app so that it can pass the review? I just don't know what they want me to add/change. I have just added a title page with a background image and iOS buttons that direct to the main section a small section and the contact us page. What else can I do?
how would you go about adding these things to a table based app
I'd start by trying to forget about what I'd already done (since that was rejected) and ask myself: how can I design this using the tools available so that the user can quickly get to the information they need?
UIPickerView comes to mind. Instead of going through three screens just to say what you want, a picker with three sections would let you select all three parameters at once.
It'd be nice if you could provide access to the information in the app several ways. What if I want to browse through all the topics? Do I have to choose one section at a to,e, or can I just start reading? A search feature would be nice, so I can find stuff even when I don't know what section it's in. A tab bar and search field would be useful for these.
Perhaps the most important thing is that however it's designed, your app should look polished. It should look like you spent time making it useful and beautiful. Give it some personality.
I'm new to iPhone programming and is faced with a task to show data on of Books where the first table view shows the books in my library using the title of the book to sort and another table view to show the authors. There is a need to have a search bar on both of the table views and when used to search will show results categorized as certain results is returned according to the author and the others returned according to the title. Something similar to the search results returned by the iPod App.
Thanks in advance to all who can shed light.
From what I gather, it sounds like you need to organize this somehow. I recommend you try a tabbed-based application. Create three tabs with the first two having navigation controllers for your tables. The first tab will have the tableView that sorts by book title. The second tab will have the tableView that sorts by the author. The third tab can do the search for either case. Hopefully, that points you in the right direction.
I wonder which will be the best route for build edit forms on the iPhone, using a TableView or using a scrollview.
I need:
Support up to 15 fields (similar to contact app)
The same behavior of safari forms, where is possible go back/forward among fields, and the form center the selected field and stay there when the user end the editing
Simple layout (one field after other)
I'm looking for the most-user friendly experience. Which route has been proved to be the better?
Exist good examples of great edit forms on iPhone apps?
I would vote for a tableview organized by sections. If nothing else, it is a more common layout and most users will be familiar with it.
In either case, you will have to handle the transition from field to field with custom code.
From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.