The tab field type is designed specifically for use within the fields.
title: Project
pages: true
files: true
fields:
tab1:
label: General
type: tabs
title:
label: Title
type: text
text:
label: Text
type: textarea
tab2:
label: Details
type: tabs
technologies:
label: Technologies
type: textarea
link:
label: Link
type: url
beautiful thanks a lot! especially if u have more fields this plugin comes in really handy! 
Absolutely you right! @choki In fact, this feature should be in Kirby core alternative of headline. What do you think @bastianallgeier?
what about multiple tabs @ahmetbora? so you can not only have one tab group but other ones down below, kinda like for each section/a set of fields. not that u think i want tabs in tabs in tabs in tabs in tabs …
this is only initial version. May be on next versions…
Please add that to the core 
The “problem” with this solution is that it doesn’t really represent the structure of the fields (which fields belong to which tab - only implicit: the ones after a tab field, which isn’t actually a field, until the next one). We would rather need a blueprint structure like this:
fields:
tab1:
label: General
type: tab
fields:
title:
label: Title
type: text
text:
label: Text
type: textarea
tab2:
label: Details
type: tab
fields:
technologies:
label: Technologies
type: textarea
link:
label: Link
type: url
I know this thread is a bit old, but I’m starting to wonder what the “correct” method would be. There doesn’t really seem to be a good option if we want the blueprint to continue to represent the data storage format. That is, one editable field per data field, with nested data stored in a nested format (like the structure field). There seems to be four possibilities.
Given those options, I believe that the only viable choices are 1 and 3. Therefore, is continuing to represent the data in the blueprint in the same format as the way the data is stored important? Any thoughts?
Can you give an example of what you want to achieve?
Something like this?
I made this tabbed-interface (or “sections”) months ago.
#########################################################################
## PAGE META
#########################################################################
fields:
sectionMeta:
label: Meta
id: meta
type: tab
icon: code
pageID:
label: PageID
type: text
placeholder: home
default: home
required: true
readonly: true
width: 1/3
help: unique ID for this page
title:
label: Title
type: text
placeholder: title is shown on pages and tabs
width: 1/3
help: the title as it will appear in the main menu
icon:
label: Icon
type: icon
placeholder: icon name (apple, building, etc...)
icon: file-picture-o
width: 1/3
help: cheatsheet - http://fontawesome.io/icons
default: question
keywords:
label: Keywords (SEO)
type: tags
description:
label: Description (SEO)
type: text
icon: info
help: short description of the pages main content / goal
#########################################################################
## SLIDER
#########################################################################
sectionSlider:
label: Slider
id: slider
type: tab
icon: image
showSlider:
label: Visible on page?
text: (de-)select this checkbox in order to toggle its appearance on the homepage
type: checkbox
slides:
label: Create your slider
type: structure
modalsize: large
#########################################################################
## FEATURES
#########################################################################
sectionFeatures:
label: Features
id: features
type: tab
icon: diamond
showFeatures:
label: Visible on page?
text: (de-)select this checkbox in order to toggle its appearance on the homepage
type: checkbox
features_title:
label: Title
type: text
icon: font
width: 1/2
placeholder: short main message
features_intro:
label: Intro
type: text
icon: font
width: 1/2
placeholder: short intro message
Do you have a download link to this?
Yeah, sure - I’ll place it on a GitHub page for you.
Will do this in the next few hours and place the link in this forum.
Really great work! 
If you have any question, feel free to ask.
I did include some basic set-up information, but English is not my native language 
Forgot to mention; the version on GitHub only works with Kirby 2.2 (or higher).
I did create a version for Kirby 2.1 - but since the back-end is completely re-written, I decided to make that version deprecated.
I think, you should open new thread on Plugins section about this plugin to get feedbacks.
Thx - but I don’t need feedback
I made it solely for myself - but because someone asked for it, I decided to place it on GitHub for him / her. So I do not have any further more intention with it.
Thanks! I was more referring to what might be considered “theoretically correct.” My impression of the blueprints are that they are meant to describe the fields a page requires, not so much to describe the interface that is used to edit them. That is why I was questioning what structure for the blueprint would be most correct, as the “nested” method proposed by distantnative wouldn’t represent the data storage. (Unless the data is stored nested, which seems just as wrong.) I suppose this is a case where there isn’t really a correct answer. Unless my impression of the blueprints is just plain wrong.
Blueprints do, and actually only do, describe the editing interface. If you don’t use the Panel at all, the blueprints won’t be used at any time by your site’s code.
The nested structure proposed by @distantnative is therefore semantically correct regarding the UI structure.
IMHO, blueprints do both: